The premise that the cost of change increases exponentially as the project goes on has dominated engineering disciplines, which surfaced the necessity of upfront design. Is that the case for software?
If we model the cash flows projected for such a system, we see something like:
A
|
|
|
|
|
+--+--+--+-----------------+
| | | |
| | | |
| v v v
|
v
The project has a large upfront cost, and takes a long time to pay out. The net present value is very negative. This can be changed in a number of ways:
- Making the negative flows less negative
- Making the positive flows more positive
- Reducing the time it takes to get to positive
Reducing the cost of software development
This is often difficult to do without sacrificing quality, which in turn increases the cost. Still, a smaller team tends to run more efficiently, cost-wise. The more autonomy teams have, the fewer coupling across teams, the less communication overhead, the greater the efficiency.
Increasing the income of software development
A more successful software product that does a better job at serving its users is more valuable. We can’t guarantee that will be the case, but we can increase the likelihood of that type of success by gathering as much feedback as possible. This is far more valuable:
- when it comes from the customer
- when it is based on a real system
Throwing all our efforts into the design we first came up with is too risky. Keeping options open has tremendous pay-offs in terms of likelihood of success.
Shipping a software product sooner
Too much has been written about this. “Lean startup”, do-things-that-don’t-scale, etc.