Some thoughts on:
"Software engineering: An Idea Whose Time Has Come and Gone?" by Tom DeMarco, in IEEE Software, July/August 2009
(https://www.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf)
Tom says:
"To understand control’s real role, you need to distinguish between two drastically different kinds of projects:
- Project A will eventually cost about a million dollars and produce value of around $1.1 million.
- Project B will eventually cost about a million dollars and produce value of more than $50 million.
What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects."
This is a really important point, clearly made - but I believe it makes some assumptions that are worth digging into.
The argument is that we don't care exactly how much Project B costs (within some sensible variance), because it will pay for itself many times over. But this is only true if:
- The project actually generates money, rather than some other kind of value
- The money is generated soon enough that we can bear the initial costs
- The money returns from whence it came; the software generates value for those who paid for it, not someone else
These are the "What, When, Where" aspects of value, and these assumptions only hold true for certain types of organisation and project.
Additionally, there is the assumption that if Project B turns out to cost more than a million dollars (or whatever we originally allocated), then we may be allowed to access further funds, and overspend. For non-profit organisations driven by tight budgets, this is a big assumption.
What kind of value does the project generate?
If it does not generate monetary value (revenue), or savings of some kind (e.g. by automation), then it does not pay for itself, and we may therefore care very much about controlling costs - the only money we have is our original budget. We cannot borrow against the anticipated benefits! (Also, some types of organisation, such as government departments and agencies, are highly constrained in the borrowing that they are allowed to make).
In some cases like this, we are not so much "making an investment" as "buying a capability".
Why would we start a project that might not even pay for itself? Because there are many other valid kinds of value, such as:
- Scientific knowledge
- Health
- Justice
- Education
- Ability to trade at all - "tools of the trade" and conformance to legal requirements
- Risk mitigation / insurance
The value might be very great - but we cannot necessarily use to it to pay for the current work right now. Hence financial control cannot be avoided in these cases.
- Scientific pure research projects. Money goes in, and knowledge comes out. Of course, this might generate money at some point in the future, but this is highly uncertain.
If the software needs to be paid for from the cash currently available, then the anticipated future value does not free us from controlling current costs. We can only disregard costs (up to a point) if we have spare cash, or can borrow against the anticipated value, and if the anticipated value is monetary (and we can convince the lender that the value will clearly exceed the cost - or provide some other form of security).
(I guess that start-ups are a different case from most of my public-sector examples; but even here, the (hopefully) potentially high value of the future product does not mean we can disregard current costs! If our funding runs out before revenue comes in, the company is over. However, the process and "controls" for achieving this are very different (cf The Lean Startup), and the risk appetite is very different).
- Contingency capabilities (disaster preparation). We might choose to build systems that, in the event of natural disaster, war or other emergency, would help us to deal with it. The value of this software could be significant - but it might never be realised. In fact, we hope it is never realised! Just like insurance, it may give a return on the investment in the distant future - or never. Its value is in mitigating risk; it is probabilistic/actuarial. If realized, the value is in terms of "costs prevented" rather than revenue.
For many kinds of project, especially in the public sector, the benefits (even if financial) are often an externality - they do not return to the balance sheet of the organisation that provides the funding.
- Public health projects. Money goes in, and better health comes out. Of course, this may have various financial benefits, but they are highly diffuse and hard to measure - and the money does not come back to the department that funded the project.
- Similarly, better education is good for individuals, the economy, society. But that benefit is diffuse in both time and "space" - the money does not return directly to the schools or education authorities, or perhaps even a government department that made an investment; budgets are set at the whim of the government (maybe a different administration).
- Law enforcement and justice. Money goes in, and (e.g.) more criminals get caught. This may actually cost more money "on the books" as more prosecutions must be made etc. Again, any financial benefits are diffuse in both time and space.
I've covered several of the types of value in the "When" and "Where" sections. One further type from the list:
- "Tools of the trade": What is the value of a hammer to a carpenter? Without one, they have no livelihood. But they are unlikely to be heedless of the cost, because they have other tools, costs and overheads to deal with. Similarly, software to meet mandatory regulations (taxes, safety, etc) is a vital enabler to value, but doesn't generate value in itself.
Tom says "I’m suggesting that first we need to select projects where precise control won’t matter so much. "
I agree with this, to the extent that we actually have a choice. Of course, we should not be willingly choosing commercial projects with a low return, unless we have nothing better! Nor should we be wasting money on poor science, or poor education, even though we expect no immediate financial returns.
But there are many efforts that are highly desirable (as discussed above), but have to be implemented from a fixed, tight budget.
Tom then says (after his analogy with the teenager): "So, how do you manage a project without controlling it? Well, you manage the people and control the time and money."
I'm unclear precisely what Tom means by the word "control" here, given that he says we "manage without controlling" via "control" (of time and money). This seems to be redefining the word halfway through the sentence. However, he clarifies that he means iterative development.
This is of course an excellent approach in general, and especially under a tight budget. Except when it isn't.
I've worked on a number of projects where we were able to iterate and deliver genuinely valuable increments on a weekly or even daily basis, or even faster on occasion. And I have worked on others where no truly valuable subset could be found to deliver; the customer, on a tight budget, had already whittled down the requirements almost to the bare essentials (not entirely - perhaps 75-80% was essential). The nature of the system was that it did one thing, in a series of essential data transformations. We went through all the usual "story splitting" ideas, but without much reduction in the minimum scope.
In such cases, an iterative approach is still invaluable for uncovering and managing technical risk. But it does not fully address the overall business risk of running out of money before the 75-80% is delivered. Nor does any other approach. I am not arguing against iterative development, just pointing out that its risk-management benefits depend strongly on the type of system under development, and the proportion of "must-have" requirements to make the system work at all.