Getting Back To Coding - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Software // Enterprise Applications

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.

Prior to joining Dr. Dobb's Journal, Andrew Binstock worked as a technology analyst, as well as a columnist for SD Times, a reviewer for InfoWorld, and the editor of UNIX Review. Before that, he was a senior manager at Price Waterhouse. He began his career in software ... View Full Bio

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Andrew Binstock
50%
50%
Andrew Binstock,
User Rank: Author
7/31/2014 | 5:55:15 PM
Getting back to coding
Tom, I'm not sure what you mean by "worse" tools. The equivalence of "better" with "more features" is part of the problem, IMHO, if not the problem. It will be a good day when what makes tools better or worse is not the number of features, but the ease of use and quality of implementation. 

So, to respond directly, I do not advocate in this article (or outside of it) that developers use worse tools. I do advocate that they choose the right tools for their specific situation, rather than choose tools that add complexity for features that won't be used. 
Thomas Claburn
50%
50%
Thomas Claburn,
User Rank: Author
7/31/2014 | 4:58:12 PM
YAGNI
Sometimes you're better served by worse tools. Too much flexibility can lead to paralysis.
Commentary
Enterprise Guide to Edge Computing
Cathleen Gagne, Managing Editor, InformationWeek,  10/15/2019
News
Rethinking IT: Tech Investments that Drive Business Growth
Jessica Davis, Senior Editor, Enterprise Apps,  10/3/2019
Slideshows
IT Careers: 12 Job Skills in Demand for 2020
Cynthia Harvey, Freelance Journalist, InformationWeek,  10/1/2019
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Getting Started With Emerging Technologies
Looking to help your enterprise IT team ease the stress of putting new/emerging technologies such as AI, machine learning and IoT to work for their organizations? There are a few ways to get off on the right foot. In this report we share some expert advice on how to approach some of these seemingly daunting tech challenges.
Slideshows
Flash Poll