That’s the title for my blog, and it’s a philosophy I believe in 100%. Software, like many other areas of life, is not a place to cut corners (at least, certain corners). There are certain expenses you have to be willing to pay if you want a quality product that will stand the test of time; avoiding them simply pushes immediate cost now to bigger nastier costs later.
Let’s argue by analogy for a while. If you build a house, you need to put the right foundation in. A thin slab and shallow foundations may be fine if you build directly onto bedrock, but if you build on clay or “black soil”, you need something stronger. If you don’t put the right foundation down, the house will suffer severe structural damage; a house across the road from a place I used to live had such a poor foundation that not even 2 years after it was built, there were massive floor-to-ceiling cracks in the walls, and the steps to the door had moved so far away from the foundation that you could get your foot trapped in the gap!
Okay, building analogies are a bit passé. So what about lawyers? Would you hire a cheap or inexperienced lawyer to go over a contract for you? Or to represent you in court? Not if you had a choice, right? Inexperienced lawyers make mistakes, and cheap lawyers are usually cheap for a reason. Okay, maybe David Boise isn’t in your budget, but you’ll pony up for a fully qualified lawyer.
Then there’s the Vimes boots theory of economics; an expensive set of boots will last you more than a decade, while cheap shoes, at a tenth of the price, need replacing every year and don’t do a very good job most of the time anyway; you still end up with wet feet. (This is a reference to Terry Pratchett novels, in case you didn’t get it)
In short: there are certain areas in life it’s a mistake to go the cheap on. Usually, it’s anytime that you can see the immediate savings but can’t see the long-term cost; it’s a good bet that the costs will be higher (sometimes much much higher) than the savings.
Software development, my personal area of expertise, is rife with such trade-offs. Management, always under pressure to improve the bottom line, crack down in lots of ways, some subtle, others not.
Need an extra developer but can’t afford someone experienced? Get a junior developer and train him or her up. Need 10 developers? Get 10 juniors… surely the senior developer (singular!) can look after them.
Under pressure to deliver on time (and in budget)? Cut back on those long-term quality initiatives, such as training, reviews, and testing. Odds are the pain from these won’t show up in this quarter’s budget sheet and that’s all that matters!
Got a fluctuating work load that means you can’t keep permanent staff busy all the time? Then understaff and supplement with contractors! Just because half the knowledge of a project walks out the door when its finished doesn’t mean it’s a bad idea. And lets face it, your permanent staff don’t have anything to do when they’re not on a project beside maintenance work anyway.
Anyway, enough describing my current workplace (kidding!), and I’ll get back to the thrust of the article: Software is too expensive to develop cheaply. This doesn’t mean you have to spend through the nose over-engineering everything. What it does mean is that if you make cuts to reduce short term costs, you’ve probably either increased long-term costs or sacrificed long-term gains. And, unlike the immediate savings from cutting corners, these longer-term costs may never be clearly visible. They are, however, very real.
 There’s a lovely quote in Cockburn’s “Agile Software Development”; he had a project that needed 6 good developers to build it. He couldn’t get six good developers, so he made do with 26 more average developers.