A beginner to software development might model it like this:
This shows two activities in software development: you pay software developers to produce features and then sell those features to customers. It’s about the best you can do without having experience in the field. There is a methodology based on this model. It’s called Code and Fix.
Martin Fowler recently wrote about design stamina. Among other things he said:
Indeed I’ve come across the impression a couple of times that design effort is tolerated to keep the programmers happy even though it reduces speed.
Here’s how I conceptualize it. A software development novice — a manager perhaps — hears about “code quality” and that “design” is used to produce it. Design costs money and code quality helps developers write features faster.
The problem is, he doesn’t know of how much design is worth compared with just writing features without design. Undervaluing design leads to bad code quality and keeping to code-and-fix. Overvaluing it leads to analysis paralysis (in big design up front) or just low velocity (in agile methodologies).
Fowler presents a pseudo-graph of two hypothetical projects, one with design and one without:
Design builds stamina that helps keep the productivity high. Although design costs more early on, once a payoff line is reached, it beats the code-and-fix development. Most experienced software developers would agree on the idea behind this model. The interesting question is the location of the payoff line. Fowler says:
Even with people who accept the design stamina hypothesis there is substantial, and important, differences over where the payoff line sits. I take the view that it’s much lower than most people think: usually weeks not months. But again this can only be a judgment call.
Our software development novice cannot make the judgement about the value of design, because his conceptual model is not rich enough. The general phenomenon here is that there are many sides to learning:
- Recognizing new resources. (Code Quality)
- Learning how resources help create other resources. (Money ==Design==> Code Quality)
- Finding the right resource exchange rates. (The location of the payoff line.)
- Improving the efficiency of resource creation. (Designing better and faster.)
Learning only one side is superficial adoption of the knowledge. It is never enough.
Sarah A. Sheard’s excellent Life Cycle of a Silver Bullet inspires another example of superficial adoption. Say that a CEO decides to hop into the agile bandwagon, and mandates the following methods to be used in every project:
This will not work. The methods are just the surface. The core of agile is the identification of the key resources and their worth. The agile values, if you will.
Adopting agile methods fits the number 4 in the list above. They are good practices (some would say they are the best practices) to create different resources: TDD helps write better tests and better code, continuous integration helps visibility, and so on. They are useless if the developers don’t understand the meaning of those resources. The developers would not know when and how much to do each activity: when to add tests, when to refactor, when to add new features.
Having a more complete picture helps, but is still not enough. There’s the task of finding the worth of each resource. But, that can only be a judgment call.