Keep it small and agile

There’s the eternal debate that is always raging anywhere that software is written: How much design should we do up front before we start coding?

Should you plan everything out first? Or maybe just get the big ideas, start coding, and then patch as you work out the details.

There are upsides and down sides to both arguments, but I think the truth lies closer to the “get the big idea and get rolling”. That is one of the ideas behind agile development, keep your design simple and flexible so that you can start on the project but make updates as necessary.

I like the organic-ness of this idea. Every application big or small boils down to one or two simple ideas. In truly great software, those ideas are the guiding principals that help shape the way the application looks and behaves. In not-so-great software the original ideas get eclipsed by other peripheral ideas and the application as a whole suffers.

At first glance this probably looks like the KISS principal (Keep It Simple Stupid), but it goes deeper than that. The concept is to pick something, stick with it, and follow through. By keeping you code “agile” you can adapt as the situation dictates, hopefully keeping your code pointing in the same general as the core idea of the application.

Joel has a great story about keeping your application focused and agile. His experience shows that there are some pretty serious advantages to keeping your business operation small. Once a company/organization reaches a certain size, its difficult or impossible to do the necessary things to make the product right. Its purely a matter of having “too many cooks in the kitchen”.

Small organization. Agile code. Superior product.