Done is better than Perfect

Earlier in the week I attended a NodeJS meet-up at Hacker Dojo. Outside the event room was a sign “Done is better than perfect”.

In May of 2015  the Amtrak Northeast Regional train from Washington, D.C. bound for New York City derailed resulting in 8 deaths. Investigations revealed that this particular route did not have the advanced safety technology (“positive train control” (PTC)) meant to prevent high-speed derailments. Under current law, the rail industry must adopt the technology by the end of this year.

Last month, 6 Irish students died in Berkeley when a balcony collapsed. One of the surviving students will never walk again. Mayor Tom Bates said “investigators believe the wood was not sealed properly at the time of construction and was damaged by moisture as a result. He said that appears to be the prime cause of Tuesday’s tragedy.”

The story is always the same.  Investigation after a horrific accident reveals that though the service was completed (done) it was not done “right”. Good practices and established processes were not followed. Just enough was done to pass an inspection or get a permit.

The Shinkansen (A.K.A Japan’s bullet train) was introduced in 1964. Over its 50-year history, carrying nearly 10 billion passengers, and traveling at speeds ranging from 120mph to 180mph, there have been no passenger fatalities due to derailments or collisions, despite frequent earthquakes and typhoons. As a young engineer on training it was a treat for me to travel on the Shinkansen from Osaka to Tokyo. I was amazed at the smoothness of the ride and marveled at the engineering feat that made it so. The Shinkansen was not built to perfection, it was just built right!

In the case of Bookout v. Toyota, Toyota was found guilty of a UA (unattended acceleration) death. It was due to a software bug which was a result of not following the established development processes. Michael Dunn in this EDN article titled “Toyota’s killer firmware: Bad design and its consequences”  provides an exhaustive explanation of the consequences of winging it. When the feds reached a settlement of $1.2B Eric Holder, the U.S. Attorney General said “When car owners get behind the wheel, they have a right to expect that their vehicle is safe. If any part of the automobile turns out to have safety issues, the car company has a duty to be upfront about them, to fix them quickly, and to immediately tell the truth about the problem and its scope. Toyota violated that basic compact.”

This same concept applies to the software we write. When a user uses our software they have a basic expectation that it will function as promised. That it will function under load, in different network conditions and if it involves critical systems it will have built in redundancies.

In the everyday world where software apps govern our daily lives, the phrase “Done is better than Perfect” has a very simple definition. Build small, build well, ship often. “Build well” means do it right, follow good development and test processes, and aim for proper working functionality.

Dave Rooney in his post puts it well, “Done” and “perfect” refer to the scope of the functionality, not its quality.”

Mark Zuckerberg in his letter to his shareholders about the “hacker culture” before the IPO wrote: “…Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.” It was just about doing smaller iterations but every iteration done right. The iteration should work like the user expects.

Aileron in their post put it aptly,  “A corollary to “good is better than perfect” is “done is better than perfect”. This does not mean doing a mediocre job or producing a poor-quality product. Being done and finishing a task gives every business person an outcome. This result will give them important success or failure metrics to decide what their next step will be.”

Done right is better than perfect!