It's safe to say that out of all of the software development project problems I've come across, there's one I don't know how to solve: the tyranny of budgets. If you can provide any insight, please leave a comment below. I'd love to hear it.
A Typical Horror Story
This following is a story I've told a few times, so bear with me if you've heard it before.
A large European company was earning millions of euros (a low seven figures) from their core software and was considered a "market leader" in what they do. Their software was written in Perl, long ago, by developers who didn't understand Perl or software development. Those software developers were long gone. Thus, after well over a decade of "how can we squeeze this in" development, they had a steaming pile of ones and zeros that no self-respecting software developer would want to work on.
Fortunately, I am no self-respecting software developer. I like rebuilding legacy systems the same way my friend James loves rebuilding old cars. Except that the company didn't call me to rebuild their software. They decided that this highly profitable software was going to be thrown away and rewritten in Java. They could find more developers and the code would be "cleaner." Except, as many companies discover far too late, rewrites are often financial disasters that drag on forever. The old code base had a ton of features that were time-consuming to port over and by the time they called me to "maintain" the Perl code, a couple of years had gone by and the company only had two customers, out of hundreds, using the new system.
Given that I have a lot of experience working with legacy codebases, the initial conversations went well. I clearly understood their problem domain, I am a deep expert in this area, and I was able to identify several of their issues before I had even seen the code They were sold; I was the person who was going to help stabilize the code base earning them millions every year.
And then the trainwreck happened.
They wanted to have me part-time, on call, and pay me a junior developer's rates.
Excuse me? You're unable to maintain your core product and you're looking for a part-time junior dev for this?
"We're phasing this product out and that's all we have in our budget."
A year later, they called me back. It seems the $100/day developer they found wasn't that good of a deal after all and he eventually stopped returning their phone calls. They still didn't have the new system ready and estimated it would take at least a year before it could properly launch. Would I be interested in working with them on the legacy system?
Of course I would. This happens all the time in consulting and you either accept it or go back to being an employee.
Then they explained they wanted to have me part-time, on call, and pay me a junior developer's rates.
Fast forward to today, several years later. I check their web site and see they're still in business, but curiously, no mention is made of the core business they were in. They seem to have shifted into a related field, cunningly using the word "AI" in its description. . Maybe it was a brilliant business decision? Maybe it was a Hail Mary pass ? Maybe it was a gradual evolution? Who knows? But I suspect they didn't throw away their multi-million euro core product on a whim.
Used Cars
I've always been amazed at how many companies treat their software like a college student buying a used car. They have a limited budget. They buy that old Ford Mustang for $1,500. They complain bitterly at their maintenance costs. And their fuel costs. And their insurance costs! And the time missed from school/work dealing with said costs.
In fact, I was the one who bought that old Mustang and it was a beast. Its fuel consumption should have been measured in gallons per mile, it pissed oil all over the place and, thanks to an exhaust leak from a warped manifold, it kept burning through the wires to the starter, causing me to replace the starter every few months. That $1,500 was all I thought I could afford but it cost me a hell of a lot more than a more expensive car.
But you know what? I didn't have much of a choice. Local public transportation was a crap shoot, meaning I risked missing work and losing my job. The distance between home, work, and college meant I couldn't walk or ride a bike and I could not afford to move. It was a cheap car or drop out of school. It was all I could afford and I couldn't afford it.
Software Projects
But there is a critical difference between used cars and software projects. . It's easy to get another car, if you have the money. The same isn't true for custom software. Maybe you get a great deal on that used car or maybe it breaks down every few months and has to be repaired. Maybe the engine block cracks and you have to junk the car. Do you really want to roll those dice on your software?
The answer, for many companies, is "yes." More than once I've heard decision makers say "this makes perfect sense and would save us a lot of money in the long run, but in the short run, we don't have the budget for it."
And you know what? I get that. While it's often penny wise and pound foolish, sometimes companies just don't have the money. Or the project isn't that important to the company. . Or, as in the case of the company that kept trying to hire me part-time, sometimes it's simply inertia: "we've made a decision and now we don't have to think about it."
And the last reason is why so much of our software is rubbish.
I honestly don't know how to break a company out of that thinking, so honestly, we don't even try. We politely explain our point of view, and move on to clients who understand that buying a cheap used car is a crap shoot. But I wish I could figure out how to get more people to read Douglas Hubbard and learn that development costs are the least important aspect of estimating project value.
Today, there's a Volkswagen Golf in front of our house. It cost more to buy than that Mustang did, but it costs far less per month and will do so for a long, long time. It was a good choice.