The Right Way

My Dad always said that there's no point doing something if you're not going to do it the "Right Way" (tm).

What life has taught me is that the "Right Way" is frequently not the right way and that "Good Enough" is usually good enough. The thing about doing something the "Right Way" is that the "right-ness" depends on what you are doing. If you're reroofing your house or you're redoing your bathroom, you do it "the right way" because getting it wrong will be very painful and expensive and the risk is very high. If you're putting down some paving blocks in your backyard to make a little patio, "Good Enough" is good enough.

There's an old view of the Software Engineer sitting high upon his ivory tower writing software the "Right Way" and if the users aren't smart enough to understand how to use, then they shouldn't be allowed to use it. I still come across this frame of mind from time to time and not only is it almost always patently wrong, it is tremendously frustating because the purveyor of said "right-ness" can't understand why you can understand and gets supremely frustrated at your lack of understanding.

Feh.

At Amazon we need to move fast; be nimble and quick. In fact a recuring trend in the software development world is fast iteration. You rarely get it right the first time, so it's better to take a couple of passes at the problem, learning from mistakes along the way. It's the old joke about Microsoft taking 3 releases of any product to get it "good". The first launch gets it out the door. The second launch makes it usuable and actually gains some marketshare. The third launch is where it gets better than sliced bread.

The trick to being nimble and being able to keep operational overhead down is to walk the line between speed and quality. If try to you build the super bullet proof ivory tower system, not only is it unlikely that your 3 year project will ever launch, but it will be pretty impossible to change and bend with changing times and changing requirements. You'll build in big, hard to fix bugs early on. Building enough to get you through the next 2-3 years nets you a lighter, simpler system that is easier to iterate. And in all those fast ierations, you have many more chances to find and fix bugs. It's not "the Right Way" but the better way. :->