Getting Back To Coding

Reducing tool complexity requires mercilessly applying YAGNI (you aren't gonna need it). Resist "featuritis" and choose the tools that deliver only what you need.

Last week's editorial went viral and received literally hundreds of comments on the main developer aggregators and on this site. By and large, readers were very familiar with the frustration I expressed of not being able to code as much as I like because I'm spending time taming the tools that support my work: the IDE, the VCS, the defect tracker, test tools, and especially the build system. (I could just as easily have added the database, the deployment stack, the cloud, and so on.) My conclusion was that this tool-level complexity (as opposed to the complexity of the code itself) has turned programming into an operational activity rather than a creative one.

The pressing question is what can be done to restore a more favorable balance? The simple and obvious answer would be better tools, especially friendlier tools. It's also the least likely path to resolution. Tool vendors have several misperceptions that stand in the way. The first is a long-standing issue, which is "featuritis:" the tendency to create the perception of greater value in upgrades by adding rarely needed features. I'll return to this in a moment. The second misperception is that many tool vendors view the user experience they offer as already pretty darn good. Compared with tools we had 10 years ago or more, UIs have indeed improved significantly. But they have not improved as fast as complexity has increased. And in that gap lies the problem.

That problem is most acutely felt by two groups: solo developers and those working either in SMBs or for-hire at a client site. Those least affected are programmers at enterprises, which can afford dedicated staff to manage the toolchain, including -- especially -- the build, the testing, and the production pipeline.

Read the rest of this article on Dr. Dobb's.