Like most developers, I got into programming because I like creating stuff. Not just any stuff, but stuff other people find useful. I like the constant problem solving, the use of abstractions that exist for long periods nowhere but in my imagination, and I like seeing the transformation into a living presence. There is a joy in the steady work of creation and in its first successful test run. It is both a sense of building and consuming until at last, at long last, I can test the new feature, verify that it works, and feel the euphoric rush of frenetic little wicker gates opening and closing inside me in a triumphant, momentarily ecstatic pulsing.

All developers know this rush. And, of course, they know the steady pleasure of patient, disciplined, and deliberate work that leads to the moment. These days, however, both the consummating surge of joy and the satisfaction of the preliminary work have become very infrequent experiences.

Both vectors today point in the wrong direction: The daily work is now overwhelmed with non-coding activity; and consequently, the culminating points of joy are ever rarer and much farther apart. So much that goes between them now feels like drudgery. On private projects, I keep hearing myself spit out between expletives, "I just want to code."

For a long time, I've attributed this frustration to the complexity of today's software. The simple programs of a few hundred lines of C++ long ago disappeared from my experience. What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations  all at a significantly higher cost. Where is the joy in that?

But in fact, the cause is not the inherent complexity of software projects themselves  although it's certainly a contributing factor  but the massive overhead of handling the tools required in software development. A simple project  for example your own open-source mobile app that, say, compares your distance traveled with its equivalent distance as the crow flies. Simple in concept, likely simple to develop, but with enough coding challenges to make it interesting. To begin with, you're going to need to choose an SCM. Git is certainly the best choice if you want any community interest. The trouble with Git is that it's a whole subworld on to itself. You can use a tutorial to get you from a minimal point A to point B. But if a potential contributor wants to fork your code, you'd better understand pull requests, branching and merging, and a whole series of other operations that might or might not have counterparts in the SCMs you've used. And even if they are conceptually similar, Git almost certainly does those same actions differently.

Presuming you know the IDE/editor you're planning to use, you now need to address the build cycle. Every mobile platform has its own preferred build tool. Unless you're writing something astoundingly simple (so, not this app), you'll need to do more than just figure out a simple build script. You'll need to understand the philosophy behind the build tool: how it works, what it expects, and how to define your specific project. If you're using "convention over configuration" tools, you might discover that you've set up your project wrong and now need to go back and change the whole directory structure.

We're nowhere near done. You're going to need to deploy that app. And then you're going to have to test it on some devices. Supposing you clear those hurdles  neither one trivial  you'll need a bug tracking mechanism. Again, if you want any involvement from others, you'll need to use a commonly favored defect tracker, rather than notes to yourself or a spreadsheet. Finally, if you want to make the app available to others, you then must begin the process of getting approved by the various vendor stores. Having fun, yet? We haven't even begun to code.

Project overhead, even for simple projects, is so heavy that it's a wonder anyone can find the time to code, much less derive joy from it. Software development has become a mostly operational activity, rather than a creative one. The fundamental problem here is not the complexity of apps, but the complexity of tools. Tools have gone rather haywire during the last decade chasing shibboleths of scalability, comprehensiveness, performance. Everything except simplicity. Most tools have their own APIs and many have their own DSLs. You either must learn a new sub-language or you have to program them. In every direction, complexity is an insistent reality poised to take you away from the core development activity: coding.

The example of a mobile app is about the simplest one available. Had I chosen a Web app, we could add the overhead of dealing with the required multiplicity of languages, the elements of the deployment stack, and that great time sink, the NoSQL database. Let's not even touch on the additional complexity of the cloud. I am certainly not the only programmer to feel the exhaustion and frustration of this situation. Next week, I'll discuss how some developers and sites are getting around the problem. Meanwhile, if you've started addressing it yourself, please share your approach.

 Andrew Binstock

Editor in Chief

[email protected]

Twitter: platypusguy

Google+