Continuous Integration: Build for Disable
// February 25th, 2011 // No Comments » // Agile
I have asked myself for months, how does Google Chrome put builds out so quickly? They have a good number of developers and started with an old fashion version control system like SVN (though looks like git is being utilized now), and they put out builds every two weeks!
Build For Disable
Build feature sets so that they can easily be disabled so that incomplete features can still be continuously integrated.
This idea has intrigued me since I first read it. In nearly all development life cycles, code not ready, or features not ready are simply never merged into the production builds. This makes merging more and more difficult the longer the feature takes to complete. This causes the developers of the long-winded feature to constantly be adapting to other developers code while those other developers never are adapting to the big features until they are ready for prime time. Why can’t we continuously work together?
As developers it has been hammered into our brains that incomplete code, commented code, untested code should NEVER be checked in… It is a developer taboo that we should never do this as professionals. I think we are somewhat ignorant for going along with this for so long. Though I am not saying the opposite is the answer but lets consider how we can utilizing these taboos to really accelerate development cycles. (more…)

I have focused a lot of time optimizing a system very much like Google maps, except for the exact opposite data set, extremely volatile data. Without focusing on the details of the project, this data could change every 6 hours, to ever 15 minutes. Being service oriented and the difficulty to visualize this dataset had us utilizing the 


