Pro Developer - Throwing Money Out the Window

It's common knowledge among programmers that most of the ills of the software industry, and most particularly the companies where we work, could be solved by simply letting the technical people make the technical decisions. In fact, that sounds so obvious that you might be tempted to shake your head and wonder what planet I come from. Obviously, since this is so incredibly logical and sensible, it's a given that most companies leave management decisions to managers, and technical decisions to techies, right?

Hey, you. Yeah, you. The one in the back staring at your compiler errors. You're laughing in all the wrong places. At least let me finish, and then we can all laugh together about how silly an assumption this is. Now, as I was about to say, anyone who's ever been paid for writing code already knows that regardless of how sensible it might be to let the people with the expertise make the decisions, that's just not the way it happens in the real world. In fact, in the overall scheme of things, when it comes to decision making power, programmers are at the bottom of the food chain, whether the issue is technical or not.

In short, no matter how silly it may be, most critical technical decisions in the software development business are made by middle or upper management, a class of creature who only rarely possesses any in depth technical expertise. This, in and of itself, wouldn't be so bad. It is, after all, management's area of expertise to keep the company on track and make the sweeping decisions requiring someone with a wide angle view of the business. The problem with this scenario is that an extremely high percentage of the time, these decisions are made without consulting the technical staff about the feasibility and consequences of the decision. Worse still, management often makes decisions for their own reasons over the loud protests of their technical staff, ignoring the recommendations made by those who have the greatest skills in that arena. It's a wonder that any software ever ships at all.

Corporate Waste

In fact, the combination of project disasters and fickle or crisis driven management frequently insures that we don't ship software. Talking with an old friend and fellow programmer a few weeks ago, we tried to put a number to this. What we came up with was that of all the projects we'd worked on, only 10% of the code we'd written ever saw the light of day by being released as a product for use by customers, whether it was shrink wrapped products or internal IT systems. This means that 90% - yes, you heard me right, 90% - of all the projects we've worked on died a premature death and never saw implementation in the field. Sometimes it's a good old fashioned project disaster (I don't think I need to define that term with this crowd). Other times, it's simply capricious decision making, constantly changing direction to go with whatever is trendy or politically expedient. And of course, there's always crisis management, where a project never gets completed because it's put on hold so that we can be assigned to putting out a different fire, only to be pulled off that effort for yet another.

In other words, 9 times out of 10, all of the time, effort, blood, sweat and tears we put into those systems, not to mention the financial cost incurred, was for nothing. The code was simply thrown away. Yes, we try to stash away the clever bits of code we've written to be used later, but the rate that technology changes usually minimizes the benefits of this. Overall, it's just money out the window.

Having heard this story over and over again from developers the world over, it slowly became clear to me over the years that this wasn't an uncommon scenario. As my mind reeled over the staggering amount of waste that is the norm in the development industry, one question kept recurring over and over again. Why? Why would any company willingly throw that kind of money into the fireplace, shrug it off as business as usual, and then embark on yet another project that would ultimately suffer the same fate? If you think of a business as an organization which exists for the purpose of making a profit, your brain will eventually reboot. It just doesn't make any sense. Or does it?

Remember the Human Factor

Businesses are run by people, and people all fall prey to the frailties of human nature. When considering the matter at hand, the people in question are known as management, and they are no less human than the rest of us, no matter what speculation you might hear from programmers when hanging out by the espresso machine. That means that decisions aren't always made for the most altruistic of reasons. Every person has their own career ambitions, their own vanities and ego, and their own personal agenda.

Furthermore, they're spending someone else's money, a point not to be taken lightly. I can assure you, if the money were coming out of their personal bank accounts, you'd see an entirely different set of priorities. Instead, this money just isn't real to them. Rather, it's an abstract set of figures on a spreadsheet simply referred to as "the budget". I'm making a point of this because if you expect that mentioning the financial consequences of the decisions is all that will be necessary for the logical mind to see things your way, you're in for rapid disappointment. This isn't their money, and it's too difficult for them to translate it to the impact on their personal paycheck. It's not like they spent the family's savings on a red sports car and have to explain the decision to their significant other.

This sort of waste and history of project disasters would never happen if the techies were in charge of the decisions. However, before we get too proud of ourselves, it's worth pointing out that it would be due to a completely different motivation than making the company money. Programming is our art and our passion. We just couldn't bear the thought of pouring all that effort into our latest masterpiece and then simply tossing it in the waste bin. We're emotionally attached, and it also goes against every logical bone in our bodies. There's only one problem. We're not in charge.

We've all had the experience of arguing with our superiors until we're blue in the face, trying to explain why the technical direction they want to take is either completely pointless or disaster waiting to happen. If you didn't have the conversation out loud, you certainly had it in your head. Either way, the end result is all too often the same. We're either patronized because "we don't understand the big picture" or we're simply told, effectively, to sit down and shut up. And so, given that we work for others, in the end it's our job to do what we're told. Disaster ensues, the project dies or is swept under the rug, and then here we are in the conference room again, having exactly the same argument over yet another doomed project. I often get visions of the Flying Dutchman.