I just read Scott Bellware's [Productivity: It Comes from Software Design Rather than Software Tools][].

These bullet points — the core of his argument — are excellent (quoted here): > - Design quality is the most important factor influencing > productivity in software development > - The things that obstruct quality degrade productivity > - The reductions in productivity over time that are typical to > tool-driven software development are greater than what can be > solved by tools > - The application of tools to these problems exacerbates the quality > problem, creating a vicious cycle that accelerates exponentially > - Quality software design is the product of principles and > practices, not tools > - The typical degradation in a software's quality over time isn't > due to the nature of software, it's due to the nature of the > approaches we choose to develop and operate software Full disclosure here: I am working on a set of software tools, and a big part of my consulting for software teams is helping them install tools to support their improvement initiatives. I agree with Scott that good design is the root of all that's virtuous in software. I guess I also agree that tools are often a distraction, though I think he's drawing a direct line where the root causes go deeper. Maybe it's my embedded background, and the fact that I've worked on teams that were woefully under-equipped in terms of tools. (Or execs were sold a bill of goods and we got stuck with the resulting boat anchors and paperweights.) I just don't see an over-emphasis on tools, maybe this happens in IT more. What I do see are many opportunities for improvement. - Designs can be better communicated. If designs can be communicated better amongst the team, they can be reviewed better, which will kill bad designs before they get coded — and the feedback will help developers improve their future designs. A tool for formatting and transmission could help here. But such a tool would only be helpful to a team that already has processes in place for creating and reviewing the design. - Requirements can be managed better. Practices like Scrum seem helpful, but there are still challenges. Again, a tool can help here but only when the team has an understanding of how the tool fits into an existing process. - Existing processes and tools are overly slanted towards managing code. [By the time any requirement or design has been reduced to code, it's way too late to fix it.][] Start working on improving quality earlier in the cycle, the effort will pay off in a big way. Putting software tools in the hands of unskilled developers is like letting me go after wood with power tools: it's an expensive way to make a lot of sawdust. Better to build skills with manual processes and then introduce tools when manual chores become tedious. [Productivity: It Comes from Software Design Rather than Software Tools]: http://blog.scottbellware.com/2008/12/productivity-it-comes-from-software.html [By the time any requirement or design has been reduced to code, it's way too late to fix it.]: http://blog.bstpierre.org/five-reasons-to-slow-down