Thursday, December 9, 2010

Software can not be manufactured

As developers we all agree with the title of this post. Still, a lot of desperate managers and business owners keep pretending that software development is a manufacturing process at heart.


Requirements specifications are created by analysts, architects turn these specifications into a high-level technical vision. Designers fill out the architecture with detailed design documentation, which is handed to robot-like coders, who sleepily type in the design’s implementation. Finally, the quality inspector  receives the completed code, which doesn’t receive her stamp of approval unless it meets the original specifications. This sounds an awful lot like the typical waterfall methodology if you ask me!

It is no wonder that managers want software development to be like manufacturing. Managers understand how to make manufacturing work, we all do. We have decades of experience in how to build physical objects efficiently and accurately. So, applying what we’ve learned from manufacturing, we should be able to optimize the software development process into the well-tuned engine that our manufacturing plants have become.

Unfortunately, the manufacturing analogy doesn’t work. Things change in business, and businesspeople know that software is soft and can be changed to meet those changing requirements. This means architecture, designs, code, and tests must all be created and revised in a fashion more agile than the leanest manufacturing processes can provide. And their we have the magic word, “Agile”. In today’s rapidly changing environment, flexilibity is key and is only achievable through agile processes.

What do you think?


Dave Van den Eynde said...

Well put.

Jeremy said...

I agree with the first half ....... though when it comes to agile I don't accept that it is the magic cure all bullet, I've seen it do far more harm on far more projects than anything else.

I think "management" likes to think the word "agile" means they can change their mind when ever they like, and that producing code is skill akin to hammer out widgets.

No process will defend bad out comes from non-technical people trying to force technical teams to work in a non-intuitive way.

Agile in the vast majority of cases throws architecture and quality out the window in the hunt for short term gains.

And we all know how well that worked in the finance sector .....

Bart Wullems said...

Hi Jeremy,

I agree that agile is not the silver bullet. But applied right it can make a huge difference. In the end it's all just a matter of common sense...

Anonymous said...

I think the point is the distinction between development and manufacturing. A factory building something like automobiles engineers design, build a prototype and so on. So the result is a blueprint of a car. The worker then assembles copies based on that blueprint.

The analogies to software and factories must fail because the roles of the actors are different. In the software world the programmer is the engineer that creates a blueprint of an app. The user creates a copy of it by starting it. Before the user didn't startet it, the copy doesn't exists.

That's the classical view on the static (blueprint) and runtime (copy) on a code.

An that's I think is the misunderstanding in the management: they don't have an assembly line in the company, only engineering. An engineering can be assisted by methods and tools like 'agile'. But methods from the industrialization won't work.