Why WiX: Disrupting the Centralized Setup Cycle

Experiance suggests there are windows of opportunity for breaking the cycle of the centralized setup model. External forces are better positioned but it can also work for a individual skeptic to start the ball rolling. So where does one start breaking the cycle?

Breaking the Cycle

The cycle breaking starts by someone with influence and a longitudinal view asking the questions: why is this broken every time and must we repeat this experience the next time? This person doesn't have to be a decision maker, but it does need to be someone that the vested parties won't throw out of the room. The first answer from the parties vested in the cycle is 'of course not, it's just that the central team is not big enough and strong enough' yet. This default message says drive resources up to the higher horizontal dashed line in the model. A skeptic that's been paying attention over more than one cycle (which turns out to be difficult to find on its own): will ask the question, weren't better tools and more people the answer last time? The default answer to this question is often: those guys were idiots last time but now we know better. Same model, different people, same mistakes.

If you've maintained folks attention long enough to get this point in the conversation, the topic of model arise. What if we turned the model on its head and stopped vesting a central team, rather made everyone responsible for solving their own problem? The knee jerk response is that you couldn't get folks to care enough, they'd make a tremendous amount of mistakes, and a centralized team would have to be reformed to save the day again (this is what the vested parties are good at). What would it take to create a self-correcting system?

Looking at the disciplines required to build software, it turns out developers are the crux of both the problem and the solution. Developers are quite accustom to self correcting but they need the real time assistance from their tools. It turns out if you enable developers to run setup builds like the rest of their build process, developers are conditioned to solve this problem in a self-correcting, self-motivated, self-governing way.

Distributing to developers ends up aligning both sides: the centralized team feels like they are getting more resources and the skeptics get a new set of skills. The disruption starts here...

More tomorrow