Maybe you won’t be surprised to hear that this question comes up a fair amount. Actually, I’m kind of perpetually amazed it doesn’t come up more often than it does. What are all those programmers (and related people, like QA) doing, after all? It sounds like a simple question that deserves a simple answer, but if you’ve ever asked it, you’ve probably discovered that simple answers to this question aren’t so easy to come by.
To help understand the situation, imagine that you’re the “big boss” of a factory. Of course, there’s little more important to you than how that factory is doing. Are its products good? Are they produced in a timely manner? Is the quality high enough? How about the costs – could they be reduced?
In a real, physical factory, you could always take a tour. You could observe the machines working, see the supplies coming in, watch the work-in-process as it progressed from one stage to the next, chat with some of the workers, see the goods nearing completion. After spending some time on the shop floor, you would probably have a pretty good sense of how things were going.
Now, suppose we’re talking about a software “factory.” While you can certainly wander around the offices where the programmer’s work, it’s not likely to be a very enlightening experience. Where is the inventory? Where is the work-in-process? Where are the raw materials? Visual inspection of partly completed products (i.e., source code) is unlikely to lead to satisfaction, since you won’t know what the @#$% you’re looking at. When you’re in a car factory and want to know how close to completion a physical car is, you can probably do a pretty good job just by looking at the assembly line and the car in question. But in a software “factory,” you can’t do that. About all you can do is ask people, and experience shows that that doesn’t lead to good results either.
Describing what the programmers are doing in typical programmer terms rarely helps.
Here’s a way of categorizing what goes on in the software factory that sometimes helps outsiders understand what’s going on. Everyone in the software factory is doing one of these things:
- Keep things running – in a physical factory, these are the normal factory workers who operate the machines, move parts, etc.
- Make new or enhanced products – in a physical factory, these are the design engineers who change what is built.
- Make things more efficient – in a physical factory, these are the manufacturing engineers who make better machines, conveyor belts, holding areas, etc.
You absolutely need to have people in the “keep things running” category (line workers); without them, your factory stops working. To reduce the need for them, you need people in the “efficiency” category (manufacturing engineers). To make their work result in more valuable things, you need people in the “enhanced products” category (design engineers). Here’s how this translates in the software factory.
Keep things running (line workers)
This includes operations, maintenance, break/fix activities, things you need to do to bring new customers on-line or otherwise cope with the normal flow of customers consuming the product/service you provide. These people “keep the lights on.”
Make new or enhanced products (design engineers)
These are the people who add and/or change code in order to make the product act in new and valuable ways, essentially to get customers to keep paying, or to pay more. Their fundamental job is to bend the revenue curve. You could fire them all tomorrow (please don’t!) and things would keep running – but running exactly the way it runs today, no worse but no better.
Make things more efficient (manufacturing engineers)
In a software factory, this activity encompasses tools (source code management, the build system), re-factoring, clean-up or re-organization of code or systems, and automation of technical tasks that otherwise people (line workers) would have to do.
The lines can seem blurred between these categories in the software factory, but it is often illuminating to think in these terms, particularly when you’re trying to understand costs, investments and the relationship of software to the business.
For example, we had a company (call it M) that had a huge staff in the data center, but their service was still breaking down too frequently. They were under pressure to cut costs, and also to increase the rate of producing new services. Everyone was screaming. The people in charge of the data center wanted fewer releases to cope with, and everyone wanted to increase the investment in QA to solve the quality problem. Sound familiar? It turns out that this company had “line workers” and “design engineers,” but they had no equivalent of “manufacturing engineers,” and their software production process was simply horrible! They really needed the huge data center staff to cope with the un-runnable stuff the design engineers kept giving them. They really needed a re-think, particularly from a “manufacturing engineer” perspective, the equivalent of re-organizing and rationalizing their factory floor. When they concentrated on this as an important problem and devoted real resources to it in a smart way, everything got better: they didn’t need as many people in the data center, quality went way up and they could turn out new features more quickly.
But quite apart from making improvements, I have found that this way of thinking about things helps bring understanding to non-technical people, and a fresh perspective to the techies. Try it sometime!
Comments