design: making software <> making whistles

Why do most software producers follow principles of manufacturing that are effectively identical to makers of, say, whistles? Exampli gratia: Acme Whistles.

These guys have been making whistles - yes, whistles - since the mid-19th century. Originally a side-business for a former farm worker turned tinkerer, Acme Whistles are made to serve a surprisingly large variety of distinct whistling needs.

Yes, differerent sorts of people have very different requirements when it comes to a whistle - soccer refs have different whistle needs than policemen than dog trainers than duck hunters, right? Why should they be obliged to use the same whistle?

Their ability to deliver the right product to the right user at the right price - following a unique design and marketing sensibility - distinguishes them in an otherwise invisible marketplace.

Applied to the software world, why can't we make products tailored to the specific needs of different users? And not just once - all the time, over and over, and lightning-fast? We're not bound by the same manufacturing limitations as a whistle manufacturer, are we? We don't have to build completely different products to meet the needs of different buyers?

But wait. That's how most software is built.

When your packaging (and by association, pricing) is embodied in the physical design of your software - when you have to create a separate binary for each unique feature combination you want to ship under a unique "edition" name, you're making whistles.

When you have to stop the manufacturing process every time marketing walks into the shop with a new wacky way for users to use your product - whether it's "we need a demonstration version" or "a version with only these features that times out in a week unless you buy it, in which case it has these features, unless you upgrade it in which case it has all features". . .

. . .you're making whistles.

(More often than not, development tells marketing to "wait for the next release". By which time the customer - and in many cases the opportunity - have gone away)

When you've got nine different licensing schemes and your head of sales wants to offer a "solution" that combines all nine of them under a single license, and you decide the only way to do it fast enough is to define a manual "workflow" for generating new licenses for the constituent products and matching them with the new "master" license and another manual "workflow" to register sales (and upgrades and license transfers) with the different ERP and CRM systems that those point products are integrated with. . .

. . .yup, you're making whistles. Complicated whistles at that.

The solution isn't to do away with packaged software and go all SaaSy. Software producers need to embrace the fundamental right granted them by their Creator to reject a manufacturing process that Henry Ford would recognize, and that Deming would applaud.

If you can decouple the product definition and development steps from the product pricing and packaging steps, you're on the right path.

If you can get your development team to make everything they build "change ready" from the very beginning, you can break the linear process mindset that keeps so many software producers mired in the 19th century.

Because unlike whistles, the software package is a fluid thing that should draw from a common well of functions. The package is whatever combination of features that make sense for a given customer - priced based on the usage model that they'll embrace.