OSCON: "Good Enough" is Good Enough

by Nicole C. on Jul 29, 2013

The first session I attended on Day 2 of OSCON was “Good Enough‚Äù is Good Enough! with Alex Martelli. I can’t possibly to Alex justice in my notes below because he was an awesome and charismatic speaker, but I’ll try!

Alex started by asking us if we should always strive for perfection and anything less is unacceptable. No one raised their hands. Instead we agreed that we should release early and release often and constantly fix and improve things.

There are 3 goals that are important to both approaches:

• simplicity
• correctness
• consistency
• completeness

However they take different priority in the two approaches (“worse is better‚Äù and “right thing‚Äù coined by Richard Gabriel in 1989).

In the “worse is better‚Äù approach takes advantage of incremental development versus the ‚Äòright thing’ approach that lets the experts do their thing all the way to the end before the users get their hands on it.

These models kind of match up with Eric Raymond’s comparison of the ‚Äòcathedral’ (“the right thing‚Äù) to the ‚Äòbazaar’ (“worse is better‚Äù).

If you only want to release perfection then you have to have designed everything up font ‚Ķ and that’s just not feasible in the real world. It would take forever and ever to do this! And the stakeholders resent the “forever‚Äù part of this.

In the real world requirements change all the time and the design will vary based on the implementation and bugs are only found when the software is used. So the iterative approach is the only real world option. Good enough is only good enough if you can make it better later. This means that backward incompatibility is your friend. You don’t want to keep errors and that’s what happens with backwards compatibility.

When thinking of “perfect‚Äù think of the verb , you want to perfect your work. Perfection of the product is not an achievable state. To do this you want to use a light-weight and agile process. Revision control, code reviews and testing all need to be part of the process! Code reviews are the single best technique in perfecting your code. You also have to keep documentation up to date , if you don’t document what this code is supposed to do then how does it help the poor user , users are not mind-readers.

Given the above there is one thing you don’t want to skimp on ‚Ķ security! This is one thing you need in from the start , it’s nearly impossible to retrofit this in to the system.

When it comes to working on bugs you want to focus all of your energies on bugs that lead to irrecoverable losses. You want to make sure you release your code without these kinds of bugs though if you can. These kinds of bugs can lead to reputation losses that might not be recoverable. More often than not though these kinds of losses , as long as you fix them in a timely fashion and in a helpful way (good service is the be all and end all of a successful enterprise) , don’t usually ruin your reputation. “Customers with the highest levels of satisfaction are not those who have never had a problem, they are the ones who did have a problem and had it speedily and courteously fixed.‚Äù (the Service Recovery Paradox). We rarely think of service in an open source context , but we should!

This theory applies when talking about finding employees as well. You want the “perfect‚Äù employee , that takes forever. Pick someone who’s personality and culture matches , who’s keen to learn and knows some of what you need. This person will then improve over time with your company/code.

In conclusion we are not talking about lowering our exceptions , our dreams must be big!! The best way to change the world though is to release early, release often! We need to reach beyond ourselves and release incrementally. “Less is more!‚Äù

Check out the slides from more info!