I’m a programmer. I write business software. Programmers hate writing business software. It’s not cool, and it’s hard. Programmers won’t come out and say that it’s hard; they’ll use terms like “messy” or “uninteresting”. It’s not hard for technical reasons; it’s hard for human reasons. And we, on the whole, are not good with humans. I’m not great with them, but I’m increasingly of the opinion that they’re more interesting than machines.

Let me give you a definition of Business Software that’ll shed a bit of light on the situation: Business Software is software that isn’t used by programmers. It’s used by non-technical people, suits. It’s not useful to us. We don’t care about it. Programmers use programming tools and play video games; end of story. In fact, if the suits think it’s great, that’s a sign that it sucks.

Since we don’t use business software, we don’t know what it should do, whether it’s working right, or how to make it better. There isn’t a good, objective definition of what it’s supposed to do; it’s “whatever the user wants.” Sometimes, it’s based on bizarre business, organizational, historical, or legal requirements. There’s no way to reason it out. If you try, you’ll often find out that your perfectly logical conclusion is in fact disastrously wrong. So we have to ask the users how the software needs to work. That means sitting in meetings. With suits.

Since the users aren’t technical, they can’t just tell you what they want. They probably don’t know, themselves. They don’t know what the limits of the technology are. They have no idea what’s feasible. They ask all sorts of really dumb questions, and expect the impossible. They’re not good at visualizing how they’ll actually use the software. They’re usually wrong about what they think they want. And they will change their minds. So you have to bridge that gap, and you don’t get to just meet them halfway. They might be able to learn a few basic technical things, but you need to learn a lot about their business. So now you have to be the one asking a lot of dumb questions.

So just figuring out what your program needs to do is the really hard bit. You’d think that after suffering through all of that, you’d at least get to do something really cool, but no – the technical solution often turns out to be fairly straightforward, usually something involving a web server and a database. I think that’s why there’s such frantic innovation in tools and frameworks for building web applications: There are all these programmers out there trying to make the technical work interesting.

In fact, to write successful business software, you have to make it deliberately uncool. You don’t use development builds of cutting edge tools and elaborate frameworks; you use simple, stable tools that lots of other people know how to use. In business software, you’re really trying to program yourself out of a job, to make yourself replaceable. You’re trying to take all of this business knowledge, and embody it in code. I’ve heard programmers brag that the guys who came after them weren’t smart enough to maintain their code. That’s completely backwards. If you’re really good, anyone should be able to pick up your code and understand what it’s doing and why. Code is communication, the expression of an idea. Your code should make all of the complex business logic clear and precise. If you’ve done really well, you can even walk non-technical people through it and give them a better understanding of their own business. If other programmers can’t work with it, you either didn’t really understand it, or you didn’t communicate it clearly.

“Legacy code” is a term of distain. It’s shorthand for “crusty old software written in some boring language on an obsolete platform.” In practical terms, it’s anything more than about 6 months old. Real legacy code can even be decades old, written back in the days of Big Iron. It’s been tweaked and stretched and hacked up ever since. It has years of business logic layered on like shellac. To work with it, you have to waste valuable brain space learning about how people did things before we Figured It Out. If you’re really skilled and really lucky, your reward will be that your business software becomes legacy code. It’ll become critical to the business and they’ll use it for years to come. The fullness of time will expose all of the mistakes and misjudgements that you made. You will learn humility, and it will make you a better programmer. It’s a tough love kinda thing.

So why do I write business software? Because I like people. I like trying to figure them out. I like trying to get my head inside their world. All of that stupid, illogical business logic? Most of it really does make sense once you learn the context and history of it. I like that it’s unintuitive; I like that little jolt of surprise I get when I learn that the world is more complex than I’d thought. I also like being useful. Just on the level of pure self-preservation, I figure I’m better off being useful rather than just clever. But I also like the feedback. I get all kinds of warm fuzzies from writing a bit of code that makes someone else’s life a little easier. I’ve come to the conclusion that I was put on this earth to program the Suck out of people’s jobs.

I started reading Adam Smith’s The Wealth of Nations. For fun. Because I’m a big dork. Right at the beginning, he talks about division of labor and pin factories. Pins: little bits of wire with a point on on end and a knob on the other. The point is that a single craftsman, without particular skill or tools, could only make a handful of pins a day. In a pin factory, the process is divided into more than a dozen stages, each simple and specific, with its own tools. This process is literally hundreds of times more productive. Businesses have been trying to pull off this trick ever since.

It worked fantastically well in the industrial age. As we moved into more of a service economy, the principle still applied, though not as strongly. In your typical office, you have specialization of skills: Managers, admin assistants, sales, marketing, and so on. In a one person company, that one person can cover all those roles. Things will go smoother when they can divide the work up among several people, but not by a factor of hundreds.

As software development has become a bigger and bigger business, the obvious thing has been to try to apply the same assembly line model: analyze, subdivide, specialize. And so we come to Enterprise Software development, which pretty much follows the old waterfall model: Requirements, architecture, design, implementation, test, support. The business analysts don’t write code, the architect doesn’t write test plans, and the programmers don’t field support calls. The business analyst writes a requirements document, the architect writes an architecture document, and so on. Each stage does their piece and throws it over the wall to the next team. The principle is sound: The more narrowly you divide up the skill set, the more specialized each group will be, and the better at their particular task. Push this far enough and eventually you can replace them with trained monkeys. Very clean, very elegant. Very efficient? Umm… no.

The problem is that there’s a significant difference between an Enterprise Software solution and a pin. A pin is a very simple thing. Everyone knows how it works and can tell at a glance if a given pin will do its job. Unless it’s bent, blunt or missing its head, it’s good to go. If an end user finds that one pin is poorly made, they just throw it away and get another.

An Enterprise Software system is not simple or obvious. Aside from the fact that even the customer often doesn’t entirely understand how they want it to work until they start using it, the amount of information that has to be communicated from stage to stage is huge. Requirements documents can be hundreds of pages. None of the workers has any innate sense of whether the information handed to them from the previous stage is complete or accurate. Every misunderstanding is multiplied down the chain. It’s like playing “telephone” with War and Peace.

The key here is that when you divide up the labor in a process, you also incur a communications cost between each stage. It’s a trade-off: Each stage can be done more efficiently, but information about the work has to be passed between them. In the pin factory, the benefit of specialization is huge, and the communications transfer is tiny – as I said, the quality of a pin is obvious. In a software shop, the benefit of specialization may be significant, but the communications overhead is enormous. To come at it from a different angle, I’ve heard it said that a programmer is lucky if they get to spend 20% of their time actually writing code. The other 80% is communications overhead: reading documents, sitting in meetings, writing documents. Add in the time you spend on rework due to miscommunication, and that 20% starts to sound generous. Here, the assembly line is actually less efficient.

So what do you do? The development of “Agile” tools and techniques is a response to this, along with component or service oriented architectures. Break the system up into independent, well-defined pieces, and put them in front of the users as quickly as possible. The catch here is that you can’t use trained monkeys. You need people who can talk to the end users and write code, who can carry the product all the way through the process. Maybe they need help from experts like domain specialists or QA engineers, maybe they can divvy up some of the work to tech writers or programmers, but the key is to capture an end-to-end understanding of the product in as few heads as possible.