Do It Right the First Time
There’s never time to do it right but always time to do it over.
Meskimen’s Law
If you think good architecture is expensive, try bad architecture.
“Big Ball of Mud”
It is so often tempting to cut corners to save a little bit of time and trouble. In the software world I see this way of thinking everywhere. People will insist they don’t have time to write tests for their software, or they’ll come back and sort out the documentation later. The first problem is of course that “later” quickly becomes “never.” But people have never been known for adequately preparing for the future, and eliminating that particular bias seems hopeless. Further, today’s world seems to move so quickly that we are often led to believe we don’t have time to do things properly. In reality, we don’t have time not to do things properly.
That’s because cutting corners often doesn’t help even in the short term. Imagine a software engineer who skips writing a set of automated tests. She saves two hours by not writing the tests, then ends up spending three hours identifying and fixing issues that her tests could easily have located immediately had she written them. Meanwhile, there are still no tests, making bugs more likely in the future as well! Another doesn’t take the time to clean up style issues in his code and has a harder time understanding what’s going on as a result, and he ends up introducing preventable errors due to his misunderstanding.
There’s software development. But this mistake is made everywhere and by everyone; if you have any doubts, you have only to consider the age and ubiquity of the phrase “penny wise, pound foolish.” Here are some common examples:
-
Lack of planning: People don’t have time or don’t want to take the time to plan out their project or design or day ahead of time, or they say they just “don’t like planning.” As a result of not taking ten minutes to plan, they make significant missteps early in the project which (again due to poor planning) are not identified until much later, undermining the entire project and necessitating massive rework. Or they spend the whole day working but never actually accomplish any of the most important tasks.
-
Buying cheap products: People buy products with lower price tags that have to be replaced in a short period of time, rather than versions that last ten times as long and cost only twice as much, despite having enough money to buy the quality product right away. Meanwhile, they get accolades for being thrifty because the bills look small.
-
Avoiding minor, one-time expenses: A manager at a company I worked for balked at purchasing a couple of $15 items without extensive information on how we would use them. The going hourly rate for employee time was more than $60, and we discussed this issue in a meeting of 5 people for about 10 minutes, at which point we had incurred more cost discussing the purchase than it would have cost to buy everything up front! If you can solve a problem by buying something cheap, and you have the money to buy it, just go buy it.
-
Refusing to learn: People consider investments in themselves – even minor ones – like learning touch-typing or keyboard shortcuts or how to jump a car – unreasonable or requiring too much time and lose out on massive gains. (The longer you spend doing something, the more time you can afford to spend improving that skill. It’s not exactly intuitive at first blush to learn that you have to type
:wqand hit Enter to quit my favorite text editor, Vim. But as a programmer, a writer, and a prolific documenter, I practically live in a document editor – probably spending a good five or six hours there on an average weekday – so it can be pretty unintuitive and slow to learn and still make good sense if it’s going to save me time once I learn it.) -
Ignoring preventative maintenance: Not doing regular 20-minute, $50 oil changes and causing thousands of dollars in car repairs is the quintessential example, but maintenance doesn’t have to involve machines. This category also includes things like regularly cleaning your home instead of doing it all at once twice a year when you have guests (likely spending hours when you have the least energy and still not doing as good a job as you’d like).
Instead of doing a bunch of things quickly and poorly and then inevitably redoing them soon at greater cost, do fewer things in a given timespan, but do them right the first time. You will often get more done even in the short term. Further, if you apply this principle diligently, in the long term you will come to spend more and more of your time doing real, valuable work with no deadline staring you down instead of scrambling to react to problems caused by bad work done earlier. Even better, valuable work doesn’t demand you suddenly drop everything and run to fix something that’s broken, which means you get to concentrate more on your work and experience fewer stressful situations, increasing your productivity – and happiness – even further in a virtuous cycle.
At first blush, this post might appear to contradict my recent post on just getting started, which argued that waiting until your work is “good” is bad and that “lousy works.” I could point out that there are always two sides to everything and sometimes one way works best and sometimes the other way works best, and leave it at that – but that’s not the whole story. I think there is in fact an important difference between these two suggestions, and moreover my admonishment to do things right the first time actually serves as an argument for the approach in “Just Get Started.”
Here’s the difference: doing things right the first time doesn’t have to mean doing them all at once. Just getting started often means doing only part of the work and then returning to the remainder later when you need to. Even if stopping partway through leaves the project in a less-than-ideal state that somebody might label “sloppy,” this methodology is vastly different from what I call cutting corners. Cutting corners is when you buy a cheap product which will soon need to be thrown away and replaced, or you ignore your software tests and thus spend more time fixing extra problems than it would have taken to just write the tests. Those things involve waste: you did some work or bought something which inherently cannot be reused later or will have to be discarded writing off all of its costs.
In contrast, the entire point of just getting started is to avoid waste. With the just-get-started methodology, you get everything you absolutely need right now done well and correctly and document what’s done and what isn’t, then leave the rest. You come back to that remainder if and when you need something you skipped before, then you’ll do the next part correctly the first time and set the rest aside, and so on. Admittedly, this does occasionally lead to doing work which has to be discarded later as the system changes, which we could regard as waste. However, unlike the other kinds of waste described above, this waste is usually not foreseeable, and experience shows the incremental approach leads to less waste overall on average.
I’ll leave you with one more little aphorism to remember next time you’re tempted to take an inappropriate shortcut:
If you’re going to half-ass something, you’re going to have to half-ass it twice.
