The root cause of software management failure derives from the manager’s continued attempt – in the face of 50 years’ evidence to the contrary – to manage software developers and software development projects as if they were managing the Model-T assembly line at Ford.
In such a simplistic model, two things could be wrong:
- whether attempting to manage software developers like assembly-line workers was wrong, or
- whether the software managers were trying to build the wrong product
Where a manager might get one of two things wrong they got both wrong. As one manager would have said, “it’s a trifecta!”
A previous post already specified the ways both managers and developers have been wrong about the definitions and treatment of software developers. But much more should be said about the software.
The software developer develops the software. This must be axiomatic. (Or cyclical… and certainly dizzying). And the all participants and spectators alike agree: developers must create the most-complete, durable, maintainable, extensible, expandable, cleanest code possible if there remains any hope of project success.
Where a manager might get one of two things wrong they got both wrong. As one manager would have said, “it’s a trifecta!”
But delivery of the software never satisfies the full-cycle requirements. That being true, software cannot be considered the product.
Software is the machine that produces the outcome: and the outcome IS the product.
Let the arguments begin.
In the 1980s budding software engineers (there’s no such thing) proudly proclaimed, “you can’t hold us to a requirement that cannot be measured.” And that was that.
But it wasn’t that. Or this. Or the other thing. It was just the cop-out that budding software engineers (repeat…) proudly proclaimed.
So the boss or client or VP In Charge of Something Very Important™ would say:
or
“Our warehouse should be able to handle more shipments and receipts with less manpower,”
or
“We want to be able to close the period faster.”
And the boss or client or VP In Charge of Something Very Important™ would say, “of course, you’re right.”
or
“Our warehouse should be able to handle twice the shipments and receipts with half the personnel,”
or
“We want to be able to close the period in one day rather than four.”
And the smug software engineer (really? again?) would counter, “It has to be measured inside our software.”
And the boss or client or VP In Charge of Something Very Important™ says, “who said that was a rule?”
It was only a rule to make the software engineer (enough, already!) more important than the customer. And it was always wrong. It wasn’t the first time experts in the software industrial complex were wrong and it wouldn’t be the last.
Satisfied that the outcome is the product, why write software? Because the software is the engine for making the outcome from the input.
In fact, the only thing that the client ever cares about or ever cared about is outcome. So let’s admit it and deal with reality.
Each of those requirements above should be considered an outcome and should be the only criteria of success. Of course the savvy software developer will barter: “I cannot guarantee a 15 percent profit, but what if we improve profit and come close? Will that make you happy?” And it should.
Satisfied that the outcome is the product, why write software? Because the software is the engine for making the outcome from the input.
Let me repeat that again, a bit more generically.
Software is the engine for making an outcome from some input.
The word engine derives from the Latin, ingenium, which translates as genius, ability, innate quality, natural disposition, invention, and even talent. We should naturally understand, then that a software engine should be able to produce an outcome if it possesses two qualities:
- It should easily digest certain kinds, and multiples of, material input.
- Depending on the input – by type, properties, and quantity – it should have the tools and logic to transform the input to a desired outcome.
Software does not produce an output from an input. It must produce an outcome from an input. Get that straight.
In fact, the only thing that the client ever cares about or ever cared about is outcome. So let’s admit it and deal with reality.
This may be the single, most-important concept in how to alter the continuing course of failing software projects in this decade.
The superior software developer must become an expert within the business domain: aware of all available and acceptable inputs in context, and fluent in the machinations necessary to produce the desired outcome. Only then can that software developer devise an automated engine that will accomplish the required outcome.
Example:
The VP In Charge of Something Very Important™ announces: “We need to increase our online sales by ten percent.”
By studying the logs (and even hiring some market research experts), the software developer discovers that many people leave the online buying experience because of an incompetent search tool and because the checkout process demands too much information.
The software developer designs a change in the look and feel (to signal friendliness) as well as improved search capabilities, combined with a streamlined checkout process.
All agree that implementing these changes should lead to increased online sales.
Chances are good they will.
Analysis:
The software developers took the outcome requirement and, knowing the context and the business domain, they looked for impediments to sales in the online process.
They broke down the domain into sub-domains that allowed them to parse the required outcome into process and logic differences as software improvements or additions (or deletions). The software engineers (stop it; just stop it!) might call these things user stories or some such twaddle. Software developers just call them code.
The whole time the software developers remained aware that they were building an engine, a machine that converted one form of input and energy to another form out output intended to alter the aforementioned outcome, which was unsatisfactory to the boss.
These changes selected and utilized different inputs than before. Inputs for both search and checkout could be re-defined, making it easier to either find the right product based on search criteria or speed the checkout asking fewer questions and requiring less input.
In some cases, even with the best software developers, the outcome is not met and the software fails. In no case should anyone blame the quality of the software code, the testing, or the precision of the coding. All of these qualities can be ideal and the outcome can still fail.
Everyone must understand that failure of outcome originates in problem analysis and engine design.
This lays a huge burden on the software developer to be right about much more than the organic shape of the software itself. And software developers must accept this new burden or else we’re all doomed to repeat history: first as rhapsody, then as free verse.
Next: What’s the Secret Faerie Dust?