Open Source: Is Build It Bigger Faster a Sound Long Term Design Plan?

Recently, I was discussing the state of economics with my brother.  He is really into history and economics (having a degree in it) and offered an interesting opinion on regarding the run down state of several metropolitan cities in the US. Recent research suggests that the present of graffiti, broken windows and litter increses the pretty crime in the area.  If you are intested, below is a link to an article about this theory (a link to the full article at Science magazine is not available):

http://www.newscientist.com/article/dn16096-graffiti-and-litter-lead-to-more-street-crime.html

It's called the "broken window" theory and whether you believe it or not is the crux of this blog post. The most interesting problem is that when the "broken window" events occur in the US that the more well to do (think wealthy) leave the area and leave the problems behind instead of participating to fix them. The US itself has a small or rather large (ironic) problem of having a large amount of undeveloped land that allow for urban sprawl. Countries such as Japan do not have the area in which to continually push urban environments out.  This encourages people to participate and fix problems instead of leaving the area so they can be ignored.  I've sort of dubbed this the "build it bigger faster" theory since you can just build bigger without addressing the shortcomings of your archtictural plan. Notice that it is not the "build it better" theory.

So is the "build it bigger faster" theory a sound long term design plan for open source software? Do more and more options to accomplish essentially the same task make a better piece of sofware?  The answer to both questions in my opinion is a resounding no.  The "faster is better" theory does not work either unless you have great software architecture in place.  Implementing new features without pause or forethought is dangerous at best and a possibily a harzard to your health if things go hopelessly wrong.  This type of development is an easy to get into because it is any easy way to please users quickly and some people have dubbed this "cowboy coding".  However, it leads to poor architectural choice down the road and literally can paint you into a corner.  While it is not a hard or fast rule, projects that frequently publish "upgrade guides" when new versions are released indicate the use of the  "build it bigger faster" theory.  Upgrade guides are usually written to help users "fix" their code because the sofware project  made poor architectural choices that require revisions later on in order to make up for shortcomings.

Good architectural choices leads to a little thought about goal for most projects called backwards compatibility.  I've talked with many people before about Mach-II and why Team Mach-II always ask if new features are backwards compatible.  For example, Mach-II 1.8 runs application written against Mach-II 1.0 (based on our dealings with people that have actually made such a large upgrade leaps).  Selling backwards compability is difficult to do becaue it is a long term  concern whereas the availability of new feature "X" is a short term thought.  Most of us think about the short term goals whereas long term goals usually take a back seat (usually to our own detriment). A good pragmatic programmer uses a blend of short term and long term goals to build better software.

Mach-II's development goals are a blend of short term and long term goals.  We have moved to more frequent release schedule (usually two releases a year) to stay in line with new features however stay true to our backwards compatibility commitment. All new feaures we develop always has enough time to "ferment" and develop a nice "bouquet" instead of hurriedly pushed into production as if it's boxed wined.

So what about this "broken window" theory? Well, it has to do with abandoning software features because they "cannot be fixed" so they can just be rebuild again better.  This is just like the inner city where people (who can afford it) just move to the suburbs instead of fixing the problem.  This happens all the time in the world of software where it's easier to just rebuild it instead of building it better in the first place.

Lastly, building it better requires time for upkeep and better planning. For example, if you build a 6,000 square foot house and plan on maintaining it yourself -- it would require more of your time for upkeep than a 2,000 square foot house.  This same analogy applies to open source since as the code base grows in size it takes more time to keep maintained.  It's another reason why Team Mach-II is really pragmatic in what goes into the framework and why we offer a lot of extension points instead of including everything AND the kitchen sink.

In closing, we use the "build it better" theory albeit at a slower pace than other projects.  Where flashy features may attract an user base, but stable and well architected features keep an user base happy.  Wouldn't you rather focus on maintaining your application instead of having to update your application with "upgrade guides" just to get feature "X"?  This is why it's important to think about backwards compatibility and long term goals when designing your application.

0 Comments  |  0 Trackbacks  |  Articles  |  Send
Posted 10/25/09 @ 5:45 AM by Peter J. Farrell