Over the past few decades, software development has gone through an “industrialization” process, evolving from craftsmanship to a process-oriented culture. Just as the assembly line and other mass production techniques in the first half of the 20th century transformed manufacturing, the introduction of software engineering practices and an ever-growing number of increasingly sophisticated tools transformed the way we build software. The transformation was so great that a very common metaphor became the “software factory” as we could build software similar to the way we build cars.
In this three part post I will discuss how the software factory came to be, why the evolution of customers’ IT preferences followed a different path, and how forward thinking organizations have moved away from the software factory by using high-performance teams to create peak experiences for their customers.
The idea behind the “software factory” was that with firmly established processes, we could specify the product, design it, code it, test it, fix it and deploy it. With good specifications would come good design, with good design would come good code, and with good code would come a good final product. With well-defined processes, the successes would be repeatable – hence the explosion of RUP adoption, ISO standards, CMM and later CMMi. It was indeed a great evolution from the previous ad-hoc model, where results were totally unpredictable. The criteria for success in this software-industrialization era were “delivery on time, within budget and with high quality” (all of which are just facets of predictability).
How did this nascent industry regard people? Well, people seemed to be virtually dispensable. The mentality was, “once we have the right process and methodology, anyone with appropriate training could do the job.” With the “software factory” concept, people were the “necessary evil” until we could have robots doing the job. I clearly remember a company, just 10 years ago, whose mission was “to eliminate the need for software development (by automating code generation).” That company went under, and I wonder why…
Building software is obviously not like making a car (or any other manufactured good in a production line for that matter), as anyone with minimum comprehension of both activities can attest. The fact that the very term “software factory” has been so widely accepted by the industry is puzzling itself. When building software you’re creating a one-of-a-kind product each time, not millions of units of it. To continue the metaphor, it would be like modifying the parts of each car, bending the hood at a different angle, adding a trailer, cutting a moon-roof, etc. all while on the production line. Instead, software development is more closely related to designing the car and building a first prototype.
At the same time, IT usage followed a very different path – from standardization in the early days to individualization today. In the beginning, users had to be content with the standard solutions provided, because that was the best anyone could get. Only the lucky ones had access to technology, so it was viewed as a gift – not as a given. Today almost everyone has some access to technology – at home, at work, and on-the-go.
The user does not follow a single stereotype – rather there are thousands of different personas. People from different countries with different behaviors and different devices. People who use technology to shop, to play games with friends, to share their lives, to find a soul mate, and to express their identity. People who update their personal tech assets very, very often. No matter how much IT wants to standardize, users continue to make their personal choices. Power has shifted to the individual technology consumer. With a plethora of devices and operating systems and a multitude of consumer behaviors, IT organizations have no choice but to cope with that as best they can.
So we have the dichotomy of an industry that moved towards a “software-factory” model as closely as it could, and we have users that progressed towards individualization of choices. Are these two things compatible? In my next post, I will discuss how these two diverging paths can come together for future project success.