I get the point the article is trying to convey. Scale increases organizational complexity and overhead relatively more than the added manpower contributes. However, the analogy with the 'milk' is far off. First of all, since the 'duplication' cost of software is near 0, buying a single seat or license is more expensive than buying in bulk. With a few exceptions, this can be established by browsing any product or SaaS website. Second, but this is minor, in retail vendors often abuse this expectation pattern and have now started to charge more per volume for the larger packages.
The production side of software is more like R&D, and there you find the diminishing returns, as iconified in DeMarco's 'the mythical man-month'.
Software Development Has Diseconomies of Scale
21–30 of 89 posts
Re: Software Development Has Diseconomies of Scale
#22Normally EVERYTHING has both economies and diseconomies of scale. You model the price per unit as the sum of different curves. Complexity not only increases on Software, but if you design a thermal engine, or a plane, or a car. Working making something as simple as fiberglass, we had something like 100 components, like tensioactives. Most of them we had no idea what they were for, as they were added like decades ago…
"But you need to control complexity as you develop."
One way to control the complexity is by consistent development of automatic regression tests which cover >90% of functionality. Then you are much less afraid if you remove something or make a big change in production grade software used by many customers.
Re: Software Development Has Diseconomies of Scale
#23It is actually a lot worse than that article suggests. There is a history of big government software projects which proved practically impossible to complete on time and on budget or to get them working at all.
Re: Software Development Has Diseconomies of Scale
#24The argument the author makes is really that software development and maintenance has diseconomies with the scale of projects and releases (basically that development and maintenance output needed scales superlinearly with complexity and output scales sublinearly with team size), which seem to be fairly widely.accepted observations in the field. There some effort to portray this as unusual compared to other industrie…
Yeah. Software development is a kind of design activity. Its' the compiler that does the "construction" bit.
Re: Software Development Has Diseconomies of Scale
#25Software has diseconomies of scale, but also has economies of scale.
For example, because of context switching: when a developer makes one change it can be pretty easy for them to add another change (everything is already "open").
Other comments here mention distribution and combining small simple tools for something larger.
Re: Software Development Has Diseconomies of Scale
#26It's not a brilliant article.
Software is not like milk. That analogy is facile and stupid.
Software should be more like civil engineering, where it's normal to unleash a big team on a big infrastructure project and still have some hope that costs and deadlines stay under control. Or maybe like movie making where there's a cast of thousands, the time is huge, and the costs are epic, but some projects stay under control - while others don't.
It's maybe more interesting to wonder what's different about software than to look for enlightenment on supermarket shelves. Because the problems stated - multiple communication channels, mistakes in modelling and testing - are handled just fine in other industries.
The crippling issues are that you can't model software, and there's not much of a culture of formal specification.
So you can't test software until you build it, requirements may change iteratively, the latest technical "solutions" often turn out to be short-lived fads, and you're always balancing between Shiny New Thing and Tarpit of Technical Debt. That's why it's hard to build. You have to build your cathedral to see if it stays up when it rains. You can't simulate it first. And even if it stays up it may be the wrong shape, or in the wrong place.
It doesn't help that management often sees software as a cost centre instead of an engine room, and doesn't want to pay a realistic rate for quality, maintainability, and good internal documentation.
Having too many people on a project is not the problem. The problem is more usually having no idea what you're doing, why you're doing it, or how you want it done - but believing that you can throw Agile or Six Sigma (etc) at it to make it work anyway, because Management Theory.
Re: Software Development Has Diseconomies of Scale
#27Bootloaders are small, but very important software. k/q is small but a very useful interpreter. There are so many examples, but it appears that to "the market" the most valued software development is large scale. The sentiment is create and contribute to large projects or go home. Stupid, but true. "Do one thing well" is more than just a UNIX philosophy. It is an essential truth. Most programs are lucky if they can d…
While some small, simple programs are great, big economic contribution is mainly in large software: manufacturing control, ERP, air-traffic control, power-plant control etc.. Small software is great, but the big economic impact belongs to big software.
Re: Software Development Has Diseconomies of Scale
#28It's not a brilliant article. Software is not like milk. That analogy is facile and stupid. Software should be more like civil engineering, where it's normal to unleash a big team on a big infrastructure project and still have some hope that costs and deadlines stay under control. Or maybe like movie making where there's a cast of thousands, the time is huge, and the costs are epic, but some projects stay under contr…
> Software should be more like civil engineering, where it's normal to unleash a big team on a big infrastructure project and still have some hope that costs and deadlines stay under control.
Since when do giant infrastructure projects meet their budget and calendar goals?
Re: Software Development Has Diseconomies of Scale
#29There are many kinds of scale. Poor performance on military projects is often an issue of huge development costs spread out over a tiny number of units. Apple spends as much to develop an iPhone as it costs to develop a new weapon system, except they sell millions of the phones so the unit cost works out ok.
I'd argue that Apple spends considerably more on the development of an iPhone than is spent on a typical defence project.
For any product which is manufactured in large quantities, the BOM will account for the vast majority of the overall cost, so limits on the cost of the BOM will significantly constrain design decisions.
These constraints are less significant for products which are sold in more limited quantities. Here, design & NRE costs predominate, leading to (very) different constraints on design decisions. In this situation, for example, it might make sense to buy a more expensive materials to make the system easier and faster to design.
Software itself isn't homogeneous. Different software products may scale in different ways. Embedded Software is different from Enterprise Software which is different from Application Software ... and so on.
Some commonality can be seen however. For example, product line engineering can be used to find commonalities and amortize design costs over a set of similar-but-distinct products ... although this is easier to achieve when you are doing bespoke work for clients than when you are producing shrink-wrap applications.
Here, you are scaling up over multiple different customisations of a design, (or multiple different members of a design family) rather than individual product elements -- but it is still an economy of scale none the less, and it is still software.
Re: Software Development Has Diseconomies of Scale
#30It's not a brilliant article. Software is not like milk. That analogy is facile and stupid. Software should be more like civil engineering, where it's normal to unleash a big team on a big infrastructure project and still have some hope that costs and deadlines stay under control. Or maybe like movie making where there's a cast of thousands, the time is huge, and the costs are epic, but some projects stay under contr…
> Software should be more like civil engineering, where it's normal to unleash a big team on a big infrastructure project and still have some hope that costs and deadlines stay under control. Since when do giant infrastructure projects meet their budget and calendar goals?
There are examples of it happening. The Gotthard base tunnel, the largest in the world, opened ahead of schedule and under budget.