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