Productivity: It Comes from Software Design Rather than Software Tools

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]: [By the time any requirement or design has been reduced to code, it's way too late to fix it.]:

Posted on 2008-12-31 by brian in process .


Hi Brian,

All good clarifying points that I agree with.

There are organizational conditions that are more conducive to communicating and sustaining the essentials of design that aren't tool-based.

However, design efforts tend to be much more effective when designs are socialized through the human relationships of the team, and only when this isn't possible are artifact-based tooling that supports asynchronous communication necessary.

Before I would opt for tool-based optimization of design communication, I would first look to removing obstructions in the environment and the organization, and use only the essential and necessary tooling within that bettered context. If I can't have an effect on the organization and environment, I fall back on material tools.

I have yet to work with an organization that I haven't been able to change to become more supportive of the essential factors for success, but I typically lean on more tools during the transition and ramp up to something more effective.

Scott Bellware
2008-12-31 22:09:00
Comments on this post are closed. If you have something to share, please send me email.