Many software projects fail, or in various ways don’t achieve the expected results. This is widely known. Loads of people offer cures, for example the fact that the critic’s favorite software development method wasn’t used, or it if was used, wasn’t used correctly. Training! Consultants! More SCRUM masters! Not just stand-up meetings, but stand-on-your-tippy-toes meetings!

There is a fatal flaw that often causes software projects to turn out badly. It’s rarely discussed. It’s sometimes called motivation, but it comes down to whether the people doing the actual work – you know, writing the lines of code – feel ownership in what they’re doing. If they don’t own the work, their eyes will be glazed over, and the most productive corners of their minds will be engaged elsewhere.

If they’re engaged, excited and feel they own the project, however, they are likely to be chastised, boxed, referred to HR, etc. Someone will sit down with them and utter phrases containing words like “team,” “supportive,” “respect other people,” and so on, all of which are generically good, I guess, but amount to something like this: “Sit down, shut down, keep your nasty opinions to yourself, stop putting other people down, and just do your work.” In other words, go through the motions.

The people who say things like this are mostly not programmers – they wouldn’t know a line of code if they tripped on it – or are sometimes go-along type programmers who see that corralling wild programmers is the path to higher pay and increasing management responsibilities – in other words, more pay for less work.

Dilbert has an on-point description of software management.

Yes, some good programmers are mean, sometimes. But mostly they just sound mean when what’s really going on is that they’re reacting strongly to stupid ideas or proposals. Because they care. The targets of their wrath should grow up and consider the possibility that they’re doing the equivalent of proposing that the race should be run by people holding their hands behind their back, or hopping on one foot. Is it nice to mock such a brain-dead idea? No. Should the person proposing the brain-dead idea be made to understand that they’d better do a brain transplant and get a brain that’s at least moderately alive, or switch jobs to serving the coffee? Yes. The sooner the better. Perhaps the idiot could even try listening to the “mean programmer” and understand the substance of what they’re saying, instead of just the emotional baggage.

That’s a nice fantasy, but very rarely happens. Most often, it’s the unrestrained programmer who is put down. Top programmers are given a clear choice. Choice 1: leave. Choice 2: do what you’re told and stop caring.

Dilbert boils it down: learn to lie.

Dedicated MBA/HR types will counter with stuff about the importance of teamwork, how the team succeeds together or fails together, the programs they run to inspire motivation, belonging and dedication to quality, and all sorts of good-sounding things. Good intentions! Sorry, but in the end, the only thing that matters is results. If your “team” has carefully included everyone and reached a consensus about the best path to get to the top of the mountain, and gets stuck part way up with nowhere to go except jumping a cliff or retreating to the base of the mountain, well they’ve failed together. I hope they’re happy. Meanwhile, some collection of misfits could be charging up the mountain in leaps and bounds, anticipating obstacles that your wonderful crowd of conformists and liars were blind to, and reacting creatively to obstacles they had failed to foresee, overcoming them quickly

This is one of the big reasons why large organizations can’t get software done: they are infected with large numbers of trained, credentialed managers and HR people who know nothing about the substance of software and are convinced that their generic management methods should reign supreme.

Software is a strange field. Its rules and patterns for career growth and advancement are unlike most others. It's thought of as a professional occupation, requiring a college degree and offering advanced degrees. At the same time, it's treated much like a manufacturing job, with no one showing any interest in how it's done other than wanting assurance that modern standard methods are used, and wanting quality results on budget and on time.

Being a software manager is better in many ways than being a software engineer. Dilbert, as usual, pretty much sums it up:

Surely there are other ways to advance a career in software than becoming a manager like pointy-hair-boss above. There are indeed. Here is a detailed description of how to climb up the ladder of status in software. Bottom line: the farther away you are from customers and actually producing working code, the higher your status. It's kind of like being a field hand on a farm. Necessary work, but everyone would rather someone else did it.

To explain what you do to people who know nothing about software, it's hard to avoid using physical metaphors to explain things — metaphors that are widely accepted but deeply misleading. And then it's easy to slip into  lying about the software, because it's invisible to anyone who doesn't look at the code — in other words, practically everyone.

Partly because of the invisibility, the compensation system is totally nuts. The star players in sports get the best salaries — everyone watches them do their thing and win! Makes sense. But in software, it's as though no one can see what happens on the field. And worse, they've never picked up a ball or bat themselves, and have no idea, visual or otherwise, how it all works. So the pay is worse.

That's part of why software is so awful. It's no secret. There have been over 50 years of attempts to make the process of building software work the way that managers imagine it should. The attempts continue to this day. They fail. Here's a bit of history on the subject.

Why keep on keeping on as a programmer? It's invisible. You are pressured to lie to get ahead. You're constrained by awful methods that are supposed to make things better but in fact make them worse. Far easier to slog through the ten seconds of guilt described by pointy-hair-boss above, and make the move.

While I was student at Harvard College, I worked at several jobs writing production software. I also audited a course at Harvard Business School. By wild coincidence, one of the jobs I had was with a small company that was the subject of a new case study used in the HBS course I took. What I learned from the contrast between the reality of the software company and the fantasy of the case study was the seed from which grew my current understanding of the application of standard management techniques to software. Bottom line: HBS-taught management techniques result in software that is expensive and bad.

How HBS case studies are written

Early in my four years at Harvard College I worked part time at a software company in Central Square in Cambridge called CPSI, Computer Programming and Systems, Inc. It was a programming services company, doing jobs for clients. I knew the languages they needed. I remember little about it or what I did there now; I remember not being impressed or excited by the work; with the campus chaos in the spring of 1969 I dropped it. Nonetheless the experience led to things that strongly shaped my career.

Not long after working at the Cambridge software company, I walked across the river to audit a course at the Harvard Business School, HBS.

The course was pretty new, called “Management of Small Enterprises: Operating Problems and Strategies.” It was a typical giant HBS course run on case studies taken from real life. The students competed to “nail the case,” by finding what HBS said was the best answer. The course was pioneering in concentrating on small business, since mostly HBS cranked out students to fill the big consulting companies and public companies. I attended to learn about starting and running a company.

Doing some research now, I found that the engaging professor, Arch R. Dooley, was a Yale and HBS grad. He never actually worked for a company, but nonetheless became an esteemed professor of manufacturing management, and started the programs for entrepreneurs, which have remained a small part of what HBS offers.

Part way through the course, which was interesting because of the type-A students fighting and clawing each other, a case study about a small software company became the focus. By the end of the case, I realized that the case was about CPSI, the company I had worked for during the prior semester. While a couple things had been changed to anonymize it, the company was easy for me to recognize. Even so, the case got important things about the company, its software and the market for software wrong. The HBS students were triumphant when they arrived at Prof Dooley’s approved approach to managing the company, which had absolutely nothing to do with what the software actually did. This blew me away.

After I graduated and stayed around Cambridge, along with a fair number of my classmates, I discovered that some of the super-bright, verbal people I knew were hired by HBS to … write case studies! They were given a bunch of existing material and case studies, with descriptions of generic “right answers” and thrown at a company. They would quickly figure out what they could and write up a cogent, compelling study. Maybe this worked for companies that did physical things they could easily understand, but none of them had the slightest exposure to software, and of course their managers were equally clueless. The result was the case study of the company I had worked for, which everyone involved thought was good material, but was in fact deeply flawed.

This HBS case study was my first exposure to the massive moat separating software reality and entrepreneurship from management and academia. Dooley was convinced that, although he’d never written a line of code and couldn’t even see it or read it, he could teach about software. He was equally convinced that, even though he’d never worked at a company, much less an entrepreneurial one, he could teach others how to do it. To this day, his colleagues think the same, and all the students and those who hire them are equally convinced. And much of it is based on case studies written by talented Harvard English majors fresh out of school.

This is stupidity, but it’s so common there has to be an explanation. I believe it’s one of the widespread manifestations of our class system, which nearly everyone implicitly understands but few people discuss. While the classes evolve, there’s always a clear hierarchy. One of the long-standing aspects of class is that people who do stuff in the real world generally are lower class than those who direct, observe or think. Attending HBS is clearly a way to enter the directing class. Engineers are highly technical, but usually other people build what they design. Programmers, by contrast, are people who use tools to build things, the way a craftsman might build a house. This puts them levels below the people who command what is to be built, just like the people who are served a meal in a grand hall are levels above the people who serve them and the cooks in the kitchen who make the food. All the grand professors at HBS and their students are far above the minions who write code in terms of class. Grand as they are, it’s clearly beneath them to stoop to dirty themselves with details of how things are built. They hire people for that. The fact that this attitude results in inefficiency, chaos and often disaster somehow isn’t their problem.

There are good reasons to teach management

The whole idea of a school teaching "management" is that there is knowledge about managing a group effort that is independent of the details of the effort and the products and services being created. This is a reasonable thought and generally valid. Think about finance, for example. Nearly every organization — even non-profits — have revenue and expenses, assets and liabilities. Expenses naturally fall into multiple categories, including payroll and capital. Different industries have different patterns of these things and the details matter, but the common elements are large and important.

Other things that are taught in business school have substantial elements that are similar across different industries. All industries have people who need to be hired, directed, and organized. Even software fits into the pattern. Suppose you're a construction company and want to build a bridge. The overall requirements of the bridge first need to be determined (number of lanes, etc.), followed by overall and detailed architectural and engineering design, and finally building. Just like software, right? It makes common sense and is widely accepted.

Why standard management fails for software

The widely accepted common sense notion that building software is pretty much like building a bridge now has a track record of many decades of failure.

Software development, security and management is an ongoing disaster, with all attempts to fix it failing. If bridges failed anywhere close to the rate of software failures, there would be revolution. See this. See this also.

One big reason is that software is different from all those things that management techniques work with. Food is cooked quickly, and you can taste the results. You can see buildings in progress and most other things. Software, by contrast, is invisible. How can you manage something you can't see?

Not being able to see it is bad, and not being able to do it yourself compounds the problem. At least with cooking and building you have a little idea of how it's done. In many fields, the best managers were good at doing what they're managing. This excellent principle is rarely followed in software.

Because of the invisibility, managers demand huge piles of documentation about the stuff they can't see. Makes things worse.

Everyone involved makes big efforts to track software as it's being built. It's often the case that glowing reports are made of software up until days prior to its being done. And then disaster ensues.

Because of its invisibility, managers tend to understand how software works in terms of metaphors — metaphors that are inappropriate and make things worse. They want to create a software factory. They think of software as being like a building, with an architect and the rest. Even the notion of "building" software, as though it were a passive thing, is wrong. It's actually extremely rare that software is "built" — mostly software is changed.

Because they're trained in business management, they think their methods apply to everything, including software. They use standard project management and variants created specifically for software like Agile to keep things under control. Without realizing the damage they cause, they insist on optimizing for predictability, while nimble startups beat them by optimizing for speed.The difference is like the difference between building bridges in peacetime or war.

Conclusion

Things have changed little since my bright college friends were churning out case studies to teach generations of future MBA's at HBS. Software is still invisible to the vast majority of managers who are nonetheless confident in the certified management methods they use, endorsed by all the Experts and high-paid people at the top of our class system. The methods that work to enable small teams to produce top-quality software quickly and well aren't secret; they are simply beneath the dignity of the people who dominate the upper ranks of all large organizations, including Big Tech.

Everyone who’s even vaguely in touch with the headlines knows there was a problem getting results from the Iowa caucuses – a problem blamed on a software app built to automate reporting voting results. No one, including the maker of the app, disputes there was a serious software problem.

Most of the commentary has focused on steps that should have been taken to assure that the app worked better than it did. The Wall Street Journal quoted various “experts” who stated – authoritatively, no doubt – that “testing could have prevented” the problems.

What’s not being said is the emperor-has-no-clothes “secret” – our society is irrationally obsessed with software, and acts convinced that getting new software to perform some function that is now getting done with older software or without software will make things better, be worth the trouble and have no downside. Otherwise sensible and experienced people continue to ignore the ongoing, rolling disaster of software building and deployment, and blissfully welcome new software nightmares, as though there’s no chance that anything could go wrong. The Iowa Democrat caucus face-plant is just the latest of a decades-long parade of software disasters. To make it explicit: I'm using this highly visible event as an occasion to illustrate a general, widespread problem; it has nothing to do with Democrats or politics.

The 2016 Caucus Software

Both Democrats and Republicans hold Caucuses in Iowa. Each party sets its own rules and changes those rules as it sees fit. They even do the voting a bit differently. Nonetheless, the parties cooperated to have a single piece of software that would service all their needs. They jointly announced this in the Jan 31, 2016 Des Moines Register:

They also had phone backup in case of software problems. The net result is that the Democrat Party chairman announced final results:

The software wasn’t perfect, of course – software never is. But it got the job done:

The 2020 Caucus Software

In the summer of 2019, the Iowa Democrats decided that, instead of upgrading the software that worked for them last time, they would pay for brand-new software to be built by a tiny, brand-new firm run by a non-programming History major who’d had a role in the tech of the 2016 campaign for Hillary Clinton. New firm. New software. Has to work out of the box, with over 1,700 people using it for the first time. No problem, right? That’s what the chair of the DNC proclaimed just hours before the caucuses opened.

Many people at the caucuses had trouble using the software, and in the end, it just didn’t work – it wasn’t able to load the results it captured from the people who were finally able to use it into the DNC reporting database. An analysis shows the kind of amateur-hour flaws you'd expect from the kind of group that built it.

Of course they forgot or ignored, like most people do, the train wreck of so many high-visibility new software unveilings, illustrated well by the ACA software releases of 2013 such as the one in Oregon I discuss here.

The Curse of Technology

Technology can be a wonderful thing. I’m grateful for the good things it delivers. But even relatively simple, physical technology can have massive problems. Did you know that 3,613,732 people have died in motor vehicle accidents in the US alone between 1899 and 2013? In 2016, 37,461 people died, as the carnage continues unabated. Just to put that number in context, the total number of US military deaths in all wars starting with the Revolution is well under half that number.

Does this surprise you? Here’s an example: during the entire period of the Vietnam war, the US had a total of 47,424 military deaths. During EACH year in the period 1966 to 1973, there were more US traffic deaths than the total for the war, with a high of 53,543 traffic deaths in 1969. You know which category of numbers people paid attention to.

The problems with computer and software technology massively dwarf those of physical technology, by huge factors.

Physical bank and stage coach robbers make for good visuals and press. One of the most famous was Willie Sutton, who spent decades in jail for having gotten about $2 million from all his hold-ups over many years. Let’s introduce computers and software to make things better! Sure. Banks lose over $10 Billion a year due to computer-driven credit card fraud alone! Banks vs. banking software? No contest.

Loads of people in the industry are promoting the latest software fad, for crypto-currency, like Bitcoin. It’s supposed to be super-secure. Sure. It turns out to be even worse, as the mounting software failures and losses demonstrate.

What all of this means is that once a piece of software does what it’s supposed to do, in production and at scale, no sensible person even thinks about replacing it with a whole new application. The reality is that most of our bedrock software systems took years to build, are often decades-old – and continue to work solidly and reliably.

An excellent example of this is the body of COBOL code produced by the small software company Paysys. When I was CTO of the company, in the late 1990’s, it ran over 150 million credit cards, including for Citibank, GE Capital and other name brands. The company was bought by the world’s largest credit card processor, First Data, and an incrementally evolved version of the same code now runs over 600 million cards, more than any other piece of software. The code is nearly 30 years old! It’s written in “obsolete” COBOL! There have multiple major attempts to re-create it using “modern” technology, sometimes with efforts taking years and costing tens of millions of dollars. Failures, every one.

The reality is that software is hard to build and get right, even today, after decades of time to figure it out. If we were as good at building bridges as we are at software, no one would dare drive over one. The big tech companies, for all their glittering reputations, are lousy software builders. When they try to build something new, they usually take years and end up failing – which is one of the reasons they acquire so many software companies, companies that in many cases have somehow managed to build software that they couldn’t. Here are details about Facebook’s ineptitude. If it's so hard for tech giants, chock full of super-bright nerds, why should anyone expect brand-new software written by a tiny group of amateurs to perform well the first time, with no testing or training, and in a national spotlight?

Building Software is different than building other technologies

People make decisions about software that, if it were any other technology, they would never make. In fact, they would consider those decisions to be beyond stupid.

Suppose you needed to get 1,700 people to an important public event from scattered places. While they didn’t all have to arrive at exactly the same, they had to be there within a couple hour window. Without fail. What would you do? You might consider asking a couple of established limo companies with fleets of reliable cars and experienced drivers to get it done. If a couple people insisted on driving themselves, you’d make sure their cars were OK and they had a backup plan. You might arrange for some car-pooling, or bring some people to a central spot and arrange for an experienced bus service with professional drivers. You might do any number of things.

Let’s further suppose you’d done something like this once, but when you did it again, you wanted to do some important things differently. Suppose you needed to make two trips on the same day. You would probably make some changes to what you did last time, while adjusting for whatever didn’t work perfectly before, right?

There are lots of things you wouldn’t even think of doing. Would you do any of the following?  Design, build and distribute brand-new vehicles for doing the transporting? Contract with a tiny, new company with no real track record to design the vehicles from scratch, not even modifying an existing model that works? Distribute the vehicles with no real test-rides? Give them to each of the 1,700 people to drive themselves? Given that the vehicles are new, not built according to standards, expect the new drivers to drive themselves with no training and no help? When the people have trouble driving, have no help available? When the vehicles break down, have no back-up plan to get the job done? When the disaster drags on for days, still be unable to fix it?

No, I don’t think any person would consider making these kinds of decisions with physical-world technology. The very thought would be ludicrous. But this is exactly what happened with the 2020 Iowa Caucus software! Endorsed and supported from the top of the DNC, and not questioned by any of the Iowa leaders!

Conclusion

There is a problem with how we think about and build software. A big problem. It’s nearly universal, and shared by normal people and supposed software experts. What happened at the 2020 Iowa Caucus technology is exceptional only in that it was so highly visible, which is why I use it as an example. The insane decision-making process that took place there takes place every day, from the way normal people and organizations work with software to the way tech giants and software so-called experts work.

The small groups of people who build software effectively and well are largely ignored by experienced managers and organizations. But these are the ones who are most likely to create amazing new bodies of software that change industries, before their software is absorbed and subsumed into the larger organizations who try to avoid breaking it too badly.

The mainstream thinking about software, both by managers and by software experts, is badly flawed. Things won't get better until fundamental things are changed.

Many things follow from the fact that software is literally invisible to most people. If you can't see it, how can you manage it? As I've detailed before.

In some cases, normal people can, at least, see some evidence of the software, like for example when it's an app or a web site. They may not choose (!) to try it themselves, but it's not too much of a stretch to think that they could.

But for some important classes of software, that's not really an option.

As usual, Dilbert explains it to us:

Note that the big boss has no easy way of knowing whether the software is "done." If it were a new web site, perhaps he could navigate to it. But what if it's a new internal process management system? Even a new customer service routing system? You could walk into a service center and see lots of people on the phone. Just like before. Is the new software done? How would they know?

Is the operating system upgrade done? How about the migration of certain applications to a virtualized environment? No one except the internal people would know the difference, unless of course a disaster happened! Hmmm… Given the track record of these things, maybe the fact that everything continued to run smoothly, with no break at all, means that nothing was changed!

There is a solution. It's pretty simple. The solution is to acknowledge that knowledge of the substance of software is more important — by far! — than supposed "knowledge" of generic management techniques as taught in business schools.

Coal mining

Knowledge of substance trumps knowledge of "management" even when you can see what's going on!

My great-great-grandfather was James Law McMillan. He was born in Wanlockhead, Scotland in the 1830's. After he came to this country, he went to work in the anthracite coal mines in the Pittston area of eastern Pennsylvania. He knew how to read and write, but had essentially no schooling. Here's part of his 1907 obituary:

He knew mining — because he was a miner. He was there, deep in the pits. No one can make the argument that mining and coal is invisible in the way software is, but James was promoted because he could get it done.

Perhaps we could learn a little from the experience of the Pennsylvania company. Get people who can do the work to do it. When you find one like this: "with such energy did he labor and such an intelligent interest did he take in his work, that he soon acquired an excellent practical knowledge of mining," that person should take on management.

In software, most managing is done by people to whom the software is invisible. And what happens too often is that the people who aren't good at programming become managers so they don't have to do it any more!

Maybe those people who ran coal mines are worth emulating, at least in this respect.

How can you manage something you can't see? Simple: you can't.

Can you see software? It depends. If you're a programmer, you can definitely see it — assuming you know the language. Can you see written human language? Only if you know the language. Yes, you can literally "see" it, but what difference does it make if the page with the language is completely meaningless to you? What if you couldn't read it, but couldn't even speak it — not just be unable to speak that language, but any language? You'd be in deep trouble, wouldn't you? Suppose you were a manager; would you be able to "manage" a bunch of writers, using the best management techniques taught at Harvard Business School? What a ridiculous thought!

But that is exactly the situation that people who are unable to write or read computer programs in any language find themselves when called upon to "manage" programmers. Here's what's truly amazing: it doesn't seem to phase these genius MBA types at all! Of course I can manage programmers, they say — I can manage anything!

There's something about software that brings out the inner stupid in managers who can't program. Here are some details and examples.

There are innumerable consequences of attempting to manage something that is invisible to you. Here's a good illustration:

It's the classic problem of setting expectations. It's the reason why I assert that, in software, dates are evil.

At the same time, I fully acknowledge that programmers, at least good ones are a different breed. It's such a big deal that I've written a whole book about it.

Just to take a trivial illustration: take a look at the Dilbert cartoon again. Notice anything? Anything jump out at you? Well, something in that cartoon jumps out to programmers. Every Dilbert cartoon is on-line and accepts comments. Here is one of the comments written by a programmer, who clearly goes right to the heart of the matter:

You think it's trivial? If so, I advise you to continue avoiding learning anything about programming. You won't make it if you try. And get some humility on the subject. Maybe you should try out some concepts that are actually appropriate for software, as opposed to jammed onto software because they're general management techniques that "work for everything." See this for more.

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!