Dec 31, 2008
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.
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.