I was inspired by J.B. Rainsberger asking, “What are the values of software?” in his talk, “The Economics of Software Design” at https://dev.tube/video/TQ9rng6YFeY , where he suggested that three of the values of software (out of “7 or 8 million”) are…
He goes into detail as to the value of each, but I kept thinking that…
The value of software is automation.
The reason we write software is to automate (business) processes. That’s what computers can do. That’s what software does.
Automating processes can be a good thing because it can…
- increase speed / performance of the operations
- improve consistency, including enforcing rules
- reduce cost and waste
But we do have to recognize the trade-offs that exist: Nothing in the world is “completely free.” When you automate a process, you have to deal with…
- loss of flexibility — ad-hoc manual processes are quite flexible
- the required up-front investment to understand the process and automate it
- the related ongoing operation and maintenance costs.
- maintenance is often the cost to achieve or regain some of that flexibility that you need.
So what about the Values of Software?
Features are good.
But features are not business value. Features that are not useful to the business users have no business value. Features that they don’t know about or don’t use have no business value. Features that they’re afraid to use have no business value.
Only features that contribute to the successful achievement of useful business process have business value. Software features that contribute to increased sales, reduced costs, and/or contributing factors like brand recognition, customer and employee satisfaction, product function, etc. have business value.
Is it true that 45% to 65% or more of features are unused?
Probably. It depends. Software built for multiple customers probably has many unused features. Purpose-built software of a single application for a single customer may have fewer unused features.
But the more requirements are “fixed up front,” rather than added incrementally as needed, the stronger the motivation to “pile in” all possible requirements — a process that inevitably leads to “feature bloat,” with many unused features. If you only get one chance to “state all the business requirements” up-front, and it will be very difficult to add or change anything later, then most people will quite sensibly try to “throw in” practically every possible thing they can think of that may have value. What would be their motivation to limit themselves to only the items with the highest overall payoff — particularly when “someone else is paying the bill”?
Also, the normal inevitable change of any business, typically around 1% change in overall “business requirements” every month, according to some sources, will inevitably “leave behind” some functionality that had business value at some time, but is no longer of use.
So it’s probably best to develop and deliver features that have high business value frequently. The feedback you get from delivering usable features that deliver business value can help prioritize subsequent work and focus it on delivering the most highly valued features first.
Design is good. Good design is good.
But a great design of a useless thing does not save it from being a useless thing.
Good design makes it more likely that the software will successfully implement the intended requirements (both functional and non-functional).
Good design typically also reduces the cost of future changes. In the best case, this might be “insightful” design — that anticipates likely future changes successfully. It would be a waste of money to invest and build for requirements that won’t be implemented until some time in the future. But allowing flexibility for future changes instead of inhibiting them can be cost effective.
There is always a risk that some entirely unexpected future requirement or opportunity will be entirely incompatible with the abstractions we used to build our current “good design.” With experience and insight as to a very rough range of plausible future changes, we can mitigate this risk. But it can never be completely eliminated.
Feedback is good.
I don’t really see software as providing feedback directly, itself. But deploying working software for real use certainly enables receiving much more useful and realistic feedback than having even highly knowledgeable people speculate as to what might happen in various hypothetical situations. Actual implementation in the “real world” often reveals unexpected details and difficulties that we could easily miss otherwise. And it’s hard to ignore or deny a problem that is actually happening, as compared to ignoring or dismissing a hypothetical problem or fear that might arise in a conceptual planning session.
Regarding the other 7-8 Million Software Values…
I think I’ll leave those to another talk or article, too. ;->