Software factories are truly excellent. They are highly reliable, with an error rate near zero. But here's the catch: software factories may be something different than what you think they are.

What Are Factories?

We all know what factories are.

A factory is one of those big plants where parts and assemblies go in one end, and through a series of steps, get turned into finished goods.

Factories have played a major role in creating the modern world, by magnifying the effort of humans with machines and power.

What are Factories Conceptually?

The purpose of a factory is to produce identical copies of a thing you already have and know how to build. Henry Ford's factory didn't produce the very first Model T — his design engineers did that.

Then they created a factory to churn out lots of copies of the original Model T. Everyone credits the Ford factory with producing cars at low cost. All factories accomplish their core function of producing copies at low cost by replacing labor with machines, and by reducing the amount and the skill of the remaining labor.

In addition, huge amounts of effort have been poured into factory cost-effectiveness and quality. Supply-chain optimization (how to most effectively get the inputs to a factory) is well-understood at this point. Similarly, both the theory and practice of factory output optimization is highly advanced. Methods for assuring consistent high quality have also been developed, starting for example with statistical process control.

The Dream of the Software Factory

We all know that software departments aren't very good at churning out great software. Wouldn't it be great if we could build a factory for software — a factory that spits out great, high-quality software, on time and on budget, just like all the other factories?

No need to dream — it's been done! There are big companies behind these factories, there are lots of books about how to build them, scary books about how it's being done better in Japan, everything you'd want.

Of course, when you look more closely, it's all hype. Most software isn't built in that kind of software factory; if it were, they'd have long since taken over software development, and no such thing has taken place.

The Reality of the Software Factory

Fortunately, there really is a software factory. It's effective, efficient, and it's quality is so near to 100% that it's not worth measuring. Furthermore, software factories are widely used — they're so much a part of programming life, that no one thinks much about them.

One of the most widely used software factories is the cp utility. This amazing utility does exactly what a factory is supposed to do — it makes you an exact copy of the thing you want to have. Amazing! This factory is also high adaptable. If you change what it is you want to churn out, it can still make a copy of it.

I wish the cp utility worked for cars. If it did, I could point it at my car and it would give me an identical copy. I could then make changes to my car, sic ol' cp on it again, and shazaam — a copy of the modified car! Cool! Sadly, cp doesn't work on cars (yet) — it only works on software — though let's not forget it also works on data, which isn't too shabby…

Factories and Software

I can only hope that people keep coming back to comparing the process of building software to a factory because computer software is so consistently bad. The motivation must be great indeed for so many people to fall for such an obviously flawed metaphor.

After all, factories are for building copies of things that are fully known and understood — like Model T cars — things that have already gone through an extensive design and prototyping process. Ooohh — I like that — let's make lots of them! Kind of like the iPhone, right? Foxcon didn't get a call from Steve Jobs asking them to start cranking out iPhones until the Apple design engineers had already designed and built them. That widely-reported last-minute switch of the glass surface of the phone happened after Steve played with the prototype and didn't like it — before the factory started doing its thing.

So repeat after me: designing is what you do to create the first copy of something; if you like it, a factory is used to crank out copies.

If you like a piece of software, cp (or the relevant copy utility) is all you need to make a copy of it! The only reason software engineers get involved is if you want something different. For which a "software factory" as properly understood is simply not relevant.

Conclusion

There's good news: Software factories exist! They are universally used in the software community! They work: they work consistently; they work quickly; they work flawlessly. Be happy.

When you're at war, your software needs to work — not in the lab, but in reality. In the field! You don't have time to test your software in the lab, and you don't care whether it works in the lab. You need field-tested software. Software that works — in the field — where you need it to work.

Normal Software QA

Normal software QA pays lots of attention to the process of defining, building and deploying software. You hear phrases like "Do it once and do it right;" "quality by design;" "we don't just test, quality is part of our process." There are lots of them. They all, one way or another, promote the illusion that mistakes can somehow be avoided, and that we can — finally — have a software release that works, and works the way it's supposed to. This time we're going to take the time, spend the money, and do it right!

How did that work out for you? Most often, it's like predictions of the end of the world. The date comes, the world is still here, and people try to avoid talking about it. Similarly with that great this-time-we're-doing-it-right release, the release comes, there are roughly the usual problems, and people try to avoid talking about it. Or there were fewer problems, but the expense and time were astronomical. Or there were fewer problems, but not much got released. Whatever.

Here are some favorite phrases: "It worked in the lab!" "How could we have anticipated that case?" "The test database just wasn't realistic enough." "Joey So-and-So really let us down on test coverage." "We had the budget to do it right, but not enough time." "We didn't have enough [tools] [training] [experienced people] [cooperation from X] [lab equipment]…" Excuses, every one. Perhaps there's a fundamental reason why we always fail?

This is a subject your CTO and your chief architect should stop ignoring and pay serious attention to. It isn't the only subject, but it sure should be #1 on the list.

QA Should be Field-Based

Who cares how the software operates anywhere except in production?? The lab environment is always different from the production environment. And the most embarassing problems are the ones where it worked in the lab but failed when deployed. The number of potential causes is endless; different machines; different loads; different network delays; different database contents; different user behavior; different practically-anything!

Given this, why wouldn't you test your software on the actual machines it will run on when it's put into production? Of course, you don't load-balance normal user traffic to the test build as though everything were hunky-dory. That's just asking for trouble. But it's not hard to send a copy of the traffic to the test machine. That alone tells you huge amounts. Did it crap out with a normal load? Now there's a real smoke test. And there's lots more you can do as well.

Conclusion

Your customers don't care how your software worked in the lab. They only care how it works for them. Yes, that's awfully self-centered, but that's just how they are, and no one is likely to talk them out of it. So live with it, and shift from pointless lab testing and back-office quality methods to actual field-testing of your software. Yes, it's messy, dirty and uncontrolled — but it's real life! It's where your software has to run! Better it should get used to it sooner rather than later.