Go fast, and make more money, by going slow.

"Get it out the door faster" by being sloppy is a costly myth.

I keep reading diatribes about how you must trade off quality for development speed, so I thought I'd write my own diatribe 😊. This speed vs. quality dichotomy is absolutely false. Buggy code is hellish to work on. Even small changes (or bug fixes) take vastly longer than it would have taken to write a few tests before you wrote the code (or in the case of unit tests, while you're writing it). If it takes longer to write tests than it does the code, you're either doing way too much work without testing or your code is too large and complex for the job at hand. (Build exactly what you need, not one semicolon more—futureproofing is a death trap.) Work small. Test small. (I'll make an exception to this more-tests-than-code rule for code that can kill people.) Check the tests into version control at the same time that you check in the code itself. It takes only a few hours to set up Jenkins or equivalent to run those tests automatically with every check-in, and you do that only once.

In addition to the bugs making it take longer to write the code out of the gate, it’s important to think about opportunity cost and the cost of delay. With high-quality code, you write it once, write it easily, and you're done. When the quality is low, when (not if) you find something wrong, you have to pay to write the code a second time. Now, add to that the opportunity cost of the code you couldn’t write because you were rewriting the first bit, and you have a minimum 3x hit (in money). But wait! There’s more! After you write that first buggy thing, you’ll be off writing something else. When that bug needs fixing, you must finish what you’re doing to get around to the fix. Those waits can easily add another 5-10x to the lead time. Also, the longer it took to find the bug, the harder it is to fix because a lot of the subsequent code that you wrote will also have to be checked and modified. That increases our 10x by as much as another 10x. Also, those changes are unsafe if there are no tests, so you have to write the tests now that you should have written at the start. All this takes time and money. So, our buggy code has increased the cost and the delivery time by a minimum of 10-20x. Every second of that delay translates to lost revenue, so the hit is even higher. In other words, your time “out the door” is at least 20x longer than it would have been if the code was good quality from day one. You can say goodbye to your competitive advantage from an early release. Good luck with that.

So, claiming you don't have time for quality is just wrong. In fact, you don't have time to have low quality, and you don't have time not to test. Bad quality, poorly tested code slows you down, costs you money, and in the case of a startup without much money, will bring down the company. Don't even think about it.

If you really want to increase your speed, do two things: (1) Make the code high quality to begin with, and (2) stop building cr*p nobody wants or needs (which you’re probably doing because, in your rush to “get it out the door,” have not been making small incremental releases for feedback or even running your “brilliant idea” by potential customers). Just stop, already!