In July, EuroPython 2013 took place in Florence, Italy for the third year in a row. A little background on me: I’m Italian and I’m a Python programmer, so that’s why I’m thrilled to share more about my experience at EuroPython. Python has an amazing community, full of some of the smartest and most inspiring people in the IT industry. After being part of this community for seven years, I can honestly say that Python conferences are all about people. The people make this community great.
One of those inspiring people is Alex Martelli, senior staff engineer at Google and member of the Python Software Foundation. He presented a keynote at EuroPython this year titled “Good Enough” is Good Enough! or, as he said, quoting Richard Gabriel: the New Jersey approach, a.k.a. “Worse is Better” versus the “MIT/Stanford approach, a.k.a. “The Right Thing.” I wasn’t sure what he’d talk about, but the title was intriguing. And one thing I’ve learned from Martelli’s keynotes over the past seven years is that when he speaks, the best thing you can do is listen, learn and take notes. So, that’s exactly what I did.
The keynote examined two different approaches to software releasing. The first one, the “The Right Thing,” recommends striving for perfection (settling for a software release that’s anywhere below “perfect” is a regrettable compromise). The second one, “Worse is Better,” says keep it simple, just good enough, launch early, launch often, get plenty of feedback (this is the “New Jersey approach” because Unix is a good example and it was written in New Jersey).
Martelli explained how Richard Gabriel identified four core values both of these approaches have in common: simplicity, correctness, consistency and completeness. He went onto explain that what really matters is the priority given to these values. Gabriel’s conclusions can be summarized by these two quotes:
The right-thing philosophy is based on letting the experts do their expert
thing all the way to the end before users get their hands on it.
Worse-is-better takes advantage of the natural advantages of incremental
development. Incremental improvement satisfies some humans needs…
He went even further, pointing out how Gabriel’s interpretation is close to what Eric Raymond described in his book, “The Cathedral and the Bazaar”, in which he described two diverging models of software development: the cathedral, where the experts are in charge and the core is all about experts doing their expert things, versus the Bazaar that is crowd-sourced and chaotic, where the crowd is in charge and includes people who are directly involved, but inevitably even people who are just helping out are there, because they need the product of the bazaar to do unrelated jobs.
Obviously, Raymond’s focus was on bugs and he believed a million eyes would make the bug discovery process faster – and that’s exactly the point. In order to have a million people looking at it, you have to release the code. You have to get it into the real world and let people use it. As Martelli said, if you want to only release “Perfection,” if you want the expert doing the expert thing, then you need “Big Design Up Front,” perfect identification of requirements, perfect architecture, perfect design, perfect implementations, etc. And it will take forever! But even more important, real life doesn’t tend to cooperate.
To quote Martelli again, “Real life doesn’t tend to cooperate.” Requirements change, and so do architecture, design, and implementation. Iterative development is the way to go. Deploy something, fix bugs, improve, use revision control, code reviews, code style, testing (if you aren’t testing,you’re asking for trouble) and last but not least, clearly document what you’ve done.
This doesn’t mean we should lower our expectations. As Martelli pointed out, “our dream must stay big, but the best way to achieve those dreams remains release early, release often.” He continued by showing examples about perfect architectures that never were implemented, released, or that lost the battle against their not-so-perfect rivals, including, Xanadu vs WWW, TCP/IP vs ISO/OSI, MIT ITS vs UNIX.
The video of the keynote is about an hour long, but I really suggest everyone who develops software should take a look at it. Even if you disagree with the conclusions, it’s a great source of information. Keynote recording: http://www.youtube.com/watch?v=gHG9FRSlPxw
My big question after the keynote was, ‘When is “good enough” is good enough?’ When does that moment come, when you’re in the middle of a development process, when you can say, “Hey, it’s time!”Thankfully, the answer to my question was already in Martelli’s keynote,, just waiting to be noticed.
Hint: here’s an excerpt from Eric Ries’, author of “The Lean Startup, article Good enough never is (or is it?). This is his definition of “minimum viable product.”
“The minimum viable product is that version of a new product which allows
a team to collect the maximum amount of validated learning with the least effort.”
There it is!That’s the answer I was looking for. Deploy something that makes someone’s life better, something that solves some real world problem. Do it as soon as it’s in a state that allows you and your team to learn from real user’s interactions, collect real data, and collect real feedback. Learn to deal with the fact that users live in the real word – and that world is imperfect. But the alternative is worse; if you just wait for your software to grow to perfection inside a cathedral, you’ll never release it.
Perfection is a process, not a state.Paraphrasing Eduardo Hughes Galeano, utopia is like trying to get to the horizon you’ll never reach, but it causes us to advance.