The Manufacturing Delusion refers to a systemic, industry-wide misconception about design and delivery of software. Namely that software is a commodity no different than any other coming off of a factory production line, such as a car or kitchen appliance.
Almost everyone in the industry falls prey to this misconception and most would argue that it is not a misconception at all. Nevertheless, as this discussion will show, it is a misconception and most of us – engineers, analysts, operators and financers of software development projects – are deluded that one can simply swap “software” for “car” or “blender” and the same economic model of manufacturing applies.
In part 3 of his 1999 seminal essay The Magic Cauldron, Eric S. Raymond outlines, what remains one of the biggest challenges in IT to this day: the myth of The Manufacturing Delusion.
To dispel prevailing myths about software development, we begin with an economic note: software, like all tools or capital goods, maintains value in its use and sets price in its sale value. Use value of a piece of software is as a tool. Sale value is as a commodity. By inertia, we tend to reason about software-production economics adopting the same ‘factory model’ we use for other commodities.
On the face of it, it is a reasonable assumption. It is founded on sensible premises that developer time is paid for by sale value and that sale value is proportional to software’s use value as well as software’s development costs i.e. the cost of resources required to replicate software functionally.
Nothing could be further from the truth. To lend from Raymond’s essay:
Use Value and Development Cost
We begin with the idea that sale value of software is linked to its use value and development costs. This is even less sound than the idea that development is paid for by software sale value.
This part of the myth is easily disproven by examining buyer behaviour. Tangible goods for which dev-cost to sale-cost proportion holds are things like food, cars and machine tools. There are even intangible goods for which sale value couples with dev cost (such as copyrights or databases). Those retain, and sometimes even increase, sale value after original suppliers are no longer around.
By contrast, when a software vendor is no longer around (because the product offer is discontinued or the vendor goes out of business) the maximum price buyers are willing to pay rapidly goes to zero. This despite its theoretical use value or development cost of a functional equivalent.
The price buyers are willing to pay for software is capped by expected future value of service a vendor can deliver on the software (broadly including fixes, enhancements and upgrades).
For Sale
We have seen above how the first part of the myth is false. To disprove that developer time is paid for by sale value, we only need to look to the fact that code written for sale comprises 5% of all code written.
The remaining 95% is written in-house. It includes most of management information systems, financial and database customizations every medium and large enterprises require. It also may include specialized code for all kinds of embedded systems: airplanes, cars, microwaves, toasters etc. as well as device drivers (despite the fact nobody makes money selling device drivers, unless you count Windows as a device driver carrier in which case Microsoft is, by proxy, the only company making money from sale of device drivers).
Most resulting software is tightly integrated into its environment in ways which make reusing or copying it too expensive, if not impossible. Irrespective of software’s environment or, in case of business operations, a set of business processes and rules governing those.
As these change, the work required is continual software upkeep. Also known as maintenance.
And, as any systems analyst will tell you, maintenance makes up to 80% of what programmers are paid to do. Accordingly, most programmer hours are spent (and most programmer salaries are paid for) writing maintenance code which has no sale value at all.
It is clear even with most inclusive definitions of ‘for sale’ that 95% of salaries are funding strictly use value of software and, even if it were an 80/20 split, the resulting economic impact would remain mostly the same.
Yesterday’s Sales with Tomorrow’s Revenues
As we’ve seen from above 2 points, ideas that
• developer time is paid for with sale value or that
• sale value is proportional to software’s use value and development cost
– are both demonstrably false.
In other words, software is a service industry operating under a persistent-if-unfounded delusion that it is a manufacturing industry. The impact is severe.
As a result of forcing round software peg into a square factory hole, price structures are out of line with actual development cost breakdown. Because 80% of a typical software project’s life-cycle costs will be in maintenance and upgrades, a price policy of charging high, fixed-purchase prices and low support fees leads to results which serve all parties poorly.
In the short run, vendors can postpone the trap by making bug-fix releases pose as new products with a new price, but customers tire of this soon enough.
In the long run, the only escape is to have no competitors, which is to say – a monopoly on the market.
As customers flock to fewer and fewer vendors, with minimal service support, the perverse incentives set up by the factory model lead to a winner-take-all market dynamic.
Vendors lose by funding indefinite-continued support expenses from a fixed-price. Customers lose in a never-ending cycle of changing vendors from a shrinking pool of choices.
Support-starvation failure kills off even the strongest of second-place competitors in all market niches – in the end, there can be only one (a pattern seen clearly and repeatedly in history of proprietary operating systems, word processors and accounting programs).
One-and-only remaining vendor’s customers are the biggest losers.
If Not Factory, Then What?
Quite simply a service-fee-dominated world. To handle the cost of software life-cycle efficiently we require a price structure founded on SLAs, licensing as well as continuous, inclusive and informative working relationships.
Healthy relationships breed healthy projects, so best approach to service delivery is by way of meaningful relationships with customers; relationships based on mutual respect, honesty and trust. These are the cornerstones upon which applying service delivery approaches are most effective in software design. Methodologies and practices like Agile and scrum serve us well but only when customised and adapted to our clients’ business limits and demands.
In the end, we all want a satisfying result. At Synthesis, we believe the way to achieve it is through a partnership with our customers; an inclusive design process which asks three things of all stakeholders: flexibility, visibility and accountability. With those three, a design process, by any name, leads to satisfying end results for customers and their customers. Take any of those away, and no matter its name, the process will yield resentment and subpar results.
By: Sasha Slankamenac, Synthesis Software Technologies
