iReconnoiter

In my opinion, distressed managers and business-owners have been fantasising that software development is a manufacturing process at heart. Software requirements specifications are churned, and software architects turn these complicated specifications into a high-level technical vision. Software designers charge up the architecture with detailed design documentation, which is handed to zombie robot-like coders, who drinks isotonic water in one hand while sleepily typing in the software design’s implementation with the other. Finally, Inspector Quality receives the completed code, which doesn’t receive his stamp of approval unless it meets the original specifications.

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

In the so-called software churning factory, the employees are the specialists. They sit faithfully at their place in the assembly line, fastening plain old Java components together. Inspector Quality is a tester by trade, software components move down the line, and he tests and stamps them in the same way each day. J2EE designers design J2EE applications. C++ coders code in C++. The world is very clean and compartmentalized.

Unfortunately, the manufacturing analogy doesn’t work here. Software is at least as malleable as software requirements. Things always change in business, and businesspeople know that software is soft and can be changed to meet those requirements. This means architecture, designs, codes, and tests must all be created and revised in a fashion more agile than the leanest manufacturing processes can provide.

In this kind of rapidly changing environment, the flexible will survive. When the pressure is on, a smart businessperson will turn to a software professional who can solve the problem at hand. So, how do you become that person whose name comes up when they’re looking for a superhero to save the day? The key is to be able to solve the problems that may arise. What are those problems? That’s right: you don’t know. Neither do I.

What I do understand is that those issues are as diverse as deployment problems, critical design flaws that need to be solved and quickly reimplemented, heterogenous systems integration, and rapid, adhoc report generation. Faced with a problem set as diverse as this, poor Inspector Quality would be passed over pretty quickly.