In our last post, we discussed two different and incompatible perspectives on software development. In this part 5 of the Open Networking Software Interlude, we look at why software development (and managing software development projects) is so hard.
Why is Software Development Hard?
Software development should be easy. We saw in an earlier post, What is Software?, that software is flexible, malleable, and has few inherent restrictions on its structure. It should be relatively easy to make software do what we want it to do.
However, developing software has long been a tricky and difficult endeavour to manage successfully.
Ultimately, the degree to which software projects proceed well or otherwise is largely due to the degree to which the project and its organisational context support the efficacy of the developer.
And where there are impairments in software developer efficacy, they are usually due to the different paradigms we outlined in the last post.
Developer Efficacy
There are four main drivers to software development productivity and all are within the control of the project sponsor and/or the organisation:
- Skill: a combination of innate capabilities + experience and training.
- Situation: the right work environment, including physical, management, etc
- Information: getting the correct and timely information from, and interaction with, stakeholders
- Tools: necessary technical resources and tools, including the selection of the correct language or development platform for the problem and the correct methodology.
Skills
This covers many different developer attributes, including innate capabilities, experience and training. Given the “theory building” model, it comes as no surprise to say that some people are just better than others.
The skills factor can only be controlled (in a project sense) by the selection of the right personnel for the job. This is not a simple task, not the least aspect of which is the relative scarcity of people with a high innate skill set.
Situation
Software developers are a highly specialised form of “knowledge worker” and need a certain type of environment to perform productively. In most environments today, however, they are located in open-plan layouts and exposed to the noise and distractions of the workplace around them.
With software developers so dependent on intense cognitive processes it should be obvious that noise and interruption will have a deleterious effect on productivity. Even the act of politely asking of someone can come back later can destroy the “flow” of a developer that may have taken several hours to build up. Promoters of open plan often respond that people can seek out one of the many “quiet rooms” that have been created when the open plan office was deployed. But they conveniently forget that these “quiet rooms” have either been converted to meeting rooms or are constantly booked.
Included in “Situation” is the relationship between developers and organisation’s management, and in particular their perspective on the nature of software development: all to frequently management’s view of software development is the production of source code alone.
Information
Getting software developers good information is critical, usually directly from the relevant business people or subject matter experts. Without good information, developers cannot build their theories.
If a developer is forced to build their model from someone else’s model (as it is encapsulated in the specification document) sometimes without direct access to the document’s authors, then the models will suffer. This scenario is associated with the traditional, so called “Waterfall” and related lifecycle models.
There are numerous Agile principle and values that inform this need, for example:
Tools
It almost goes without saying that developers need the right tools, and in principle most organisations don’t mess with this, at least superficially. However there are many ways to impact the efficacy of developers in less direct ways: inflexible procurement processes, long lead times (often driven by approvals processes) and “SOE” standards that work against procurement of new tools in a rapidly changing marketplace are all common “speed humps” that can slow down the availability of tools in a project.
Impact of the Factors on Developer Efficacy
All of these factors are within the control of the project sponsor and/or the organisation within which the project is embedded. From a project perspective, it’s mostly about personnel selection, since it is rare to embark on training or skills development during a project. The other three factors are totally within the control of the organisation and/or management team responsible for the project.
Often, the wrong decisions are made for reasons that don’t have anything to do with the project outcomes, e.g. office cost. I wonder if the push to have development teams in open plan office space would have been so strong if open plan was in fact more expensive at the unit cost level?
But consider the relative impacts of such cost savings: as a rule of thumb each of these four factors can have an order of magnitude (or even greater) impact on nett delivered productivity. So taken together, these four factors can influence productivity about up to four orders of magnitude, i.e. a range of up to 10,000 times. Practically, the payoff may be smaller, but there is no other work domain where so much is possible, but so little is done to leverage this amazing payoff.
In the real world, software development is often relegated in the mind of managers to the same level as general clerical work, its productivity equivalent to the number of pages produced each day.
The margin between a major productivity payoff and a material productivity impact is narrow. It is worth keeping these factors in mind. Does a few thousand dollars savings on furniture or floorspace or computer look so great if they impact nett development productivity to the tune of millions of dollars?
How does this play into the development of Open Networking solutions?
Stay tuned for our next post.
