This editorial was originally published on Jul 15, 2009. It is being re-run as Steve is on holiday.

I stumbled upon an old blog post by Neil Davidson that he recycled via Twitter. It was about design and how things bloat. In the post he references another blog by Moishe Lettvin , who worked on the Shutdown menu in Vista. Reading that post, I was amazed to find that 8 people directly and 43 people indirectly contributed to that feature over a year.

Really?

At first I had the amazing response that most people probably have of MS is obviously so (insert your four letter adjective here) blanked-up, no wonder Vista was late. However as I read through the comments, I saw so much disagreement over how the feature works, should work, compares with OS X, and more that I'm not sure so this was a year of development time wasted. (Note I don't know the man-years spent on this, but I bet it's > 1).

I haven't built a lot of software in my career, especially large scale or shrink wrap software, and so perhaps I don't really understand things. However I do think that we tend to over-engineer too often. I see people that try to design in every contingency, as well as think of every possible places things might go wrong. I have a simple mantra for you folks:

You can't do it. Get over it and ship something.

It sounds simple, but it's not. But it's not necessarily naïve. I've seen too many people delay releasing something, trying desperately to get things right. They're never right. They're also never done, so you might as well ship something that's 80% right and then plan on fixing it right away.

I know some people will disagree and say that things should be built right the first time. I don't think they ever are. They can be built well, but they ought to be built quickly, and with a design that expects changes to be required in  a relatively short time frame after they're released. This doesn't work for all software, but I bet it works for a large class of applications that aren't on the scale of SAP or Windows.

We can learn to code better, build more secure and stable software, but I don't think we'll ever cover all the bases. So why try? Build something that works most of the time and then refine it from there.