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.
(via http://www.mach-ii.com/index.cfm/go/blog:showEntry/entryId/8C7B1B44-D975-986B...)
I originally wrote this for the Mach-II blog, but I thought I should repost a link to this on my new Posterous. I've been thinking about how long something should "bake" before it should be allowed to into the world. There is a lot of open source software out there just doesn't get the refinements to it that make working with it a pleasure. Instead of thinking of this like something you can stick into the oven for a few more minutes, I like to think of good software development like the process of baking a good loaf of bread. Here are few items / processes for baking a nice loaf of bread and the corresponding software development part:
Premium IngredientsWell, if you're going to bake a killer loaf of organic pumpernickel bread -- you should start with the best ingredients right? Situations in software development where you need to turn lead into gold will never turn out. The old phrase of garbage in equals garbage out applies here. Let's start with nice stoned milled organic grains and filtered water for our bread. In the terms of software development, the analogous part would be thorough research, a good strategy and an architecture plan (meaning you understand the needs of what needs to be accomplished). Just because you have the perfect recipe and all the right ingredients doesn't mean it's going to turn out. This leads us to... The "Right" Tools
I don't know if you noticed, but I didn't lump in developer knowledge or skills in the last point. You cannot just buy experience and knowledge as they must be accrued over time. Just like in bread making, you might have access to a wood-fired, stone bottomed oven, however there is an art to using that as a tool. If you aren't careful, you might just bake blackened mounds of burnt crap. If you are just getting started with bread making, a loaf pan and a modern gas-fired oven might be easier for you to managed and give you better results. With time, you'll learn the tricks of using that $40k brick oven, but just realize things take time. And time is can be your best tool because... Practice Makes Perfect
If you've ever seen me speak at a conference, you've probably heard me say "software development is an iterative process." Talk about a boring phrase, albeit accurate. A more sexy phrase is "practice makes perfect." Let's pretend it's the very first time you're baking a loaf of organic caraway rye bread. Doesn't matter if you have the best ingredients, the perfect recipe and the right equipment, you'll first time won't be that artisan quality you're looking for. I think a lot of the time the phrase of "well, it's works...right?" is used as a justification for not refining the end product. There is an art to refining what you are doing and don't think you'll get it right at the first pass. Actually, I'll be the first to admit that many years ago I had a complex about "doing it right the first time." This was bad because I hemmed and hawed over the small minutia -- thinking that if I did not get it right the first time -- the whole pot would go sour. Now my philosophy is "do it your best the first time" and have the humility to realize and correct your mistakes in order to make a more perfect result. Sometimes this means you have to correct small defects in your code or add in new features. Other times you'll have to start a fresh because your implementation is like somebody that just peed in the pool -- the yellow cloud underwater is an indicator that you shouldn't hang around. Putting It All Together
So how do you make the best bread? Talk to your fellow bread bakers! Nothing exists in a vacuum and it's important to have a sounding board for your ideas. Sometimes this is easy because you work on a team of great people and sometimes you have to go it alone because you're the only person on the product. I tend to work on small teams and so my sounding board has to be me sometimes. No, I don't have multiple personalities, but I do talk out loud to myself quit a bit. Most of the research out there indicates that vocalizing your thoughts uses different parts of the brain than just thinking about them. So I'm just utilizing all the parts of my brain. I bet everybody has experienced a time where you just can't figure something out and you head over to the next cube or fire up your chat client and after the first 30 seconds of discussing something -- voila -- you'd go "d'uh" and figured out your problem before even explaining the whole thing. I recommend that talk to yourself first before wasting an other developer's time and possibly interrupting their zone. There is an art of knowing when to ask for help and when self-reliance is needed. In closing, I hope to refine my bread baking concept over time. Right now I think it's at soda crackers level. Maybe I'll attempt a better version again soon.
