Software development is product development

Updated 1/30/2010: The distinguished Bjarne Stroustrup also attacks the shop floor metaphor in his recent CACM article: ""The idea of software development as an assembly line manned by semi-skilled interchangeable workers is fundamentally flawed and wasteful.""

--------------------------------------------------------------

"Software development is not like building bridges! It's not like a shop floor! It can never be a factory! It doesn't follow a process! It's an art! A craft! Poetry!"

Variations on the above are frequent in the world of software, systems, and solutions, especially when developers are heads down writing code.

Here is a classic exploration of the issues from the esteemed Martin Fowler. And here is a characteristic dismissal of the manufacturing metaphor by Jeff Atwood.

Fowler mentions an alternative metaphor: code is design, compiling is manufacturing, and one of Atwood's commenters argues that "Software development is like software development... When will people stop trying to compare it to anything else? Metaphors are useful in small doses...Software development is about creating an entirely new thing every time."

But I think they both miss the point: the shop floor - the manufacturing operations - is the running software, manufacturing transactions (interpreted broadly; even creating a word processing document or spreadsheet can be viewed as a business transaction).

Conceiving of a transaction - and how to automate it via software - is like designing a product for manufacturing. The requirements characterize the transactional output, and the software construction is essentially designing and building the assembly line that will churn out the transactions. In some cases (e.g. enterprise ERP) the assembly line is unique; in other cases (e.g. desktop tools) it itself will be replicated any number of times... the same way that some manufacturing is franchised (e.g. fast food outlets). 

This implies, if we are seeking industrial analogies, that we need to look upstream of the manufacturing operation, to product development. And there we find a very different world from the stereotyped shop floor. We find one that is in fact uncertain, iterative, expensive, and above all risky. Sounds like software development to me...

We also find a portfolio management problem; just Google "product portfolio management" and you'll see what I mean.

So, if the running software is the shop floor, where does Lean fit? Turns out we've been doing it all along under the guise of performance optimization. The "constraint" to pumping out value might be a performance bottleneck between the application server and database. Or the WAN between corporate HQ & a regional facility. Recurrent Incidents that have become a Problem. We've got plenty of tools & experience in these sorts of things!

What I am wondering, is what does the field of classic product development have to offer service development? I agree that Product subtypes into Good and Service. But we (as an industry) are just starting the journey into IT Service Portfolio Management, and I have seen little if any attempt to draw learnings from the better established field of (Manufactured Good) Product Portfolio Management.

And in particular, beyond "designing for manufacture" (the equivalent of nonfunctional requirements), where is the intersection of Lean with new product development?

Got something to say?