I have just returned from a month-long vacation, enjoying an overdue change of context. Among other things, it helped me free up enough brain cycles to play one of my favorite games – ‘look for a pattern’.
It appears (as my Jazz Platform colleagues tell me) that I have a giant database for a brain. Anything that enters is promptly tagged and also grouped together with existing entries that somehow match. This gift allows me to entertain/annoy friends and family with speeches that start with “that reminds of me of a movie/song/novel/article in which…”. I would like to take credit for this ability but there is nothing I did to develop it. Although I am diligently working on sabotaging it through my newly acquired taste for single malt whiskeys.
My colleagues are always amused that no matter how tangential the detour is, there is always a point where I bring the narrative back to what Ward Cunningham liked to call ‘aha moment’, where it all suddenly makes sense. Allow me to try to bring you to such a moment via a very meandering path.
In 1997 I had a lot of pleasure watching a two-part docudrama about a Canadian attempt at greatness via a bold new supersonic fighter jet design called Avro Arrow (also a reminder of how much weight Dan Aykroyd put on since The Blues Brothers). The movie caused a small (albeit polite) burst of patriotism in Canada. My takeaway from the movie was a detail where they attempted to build a completely new airframe, and a completely new engine at the same time. It was never done before – normally a new design would use tried and tested engines (Rolls-Royce, in this instance). My favorite quote of the government official displeased with this risk taking: “It’s a little bit like wearing two left shoes. It may be distinctive, but it’s not too bright”. File under: minimize number of variables.
Many years later, and completely unrelated, I stumbled upon a project model called Tick-Tock practiced by Intel. Using this model, Intel starts with an established micro-architecture and shrinks the process technology (a ‘tick’), followed by a new micro-architecture once the process is proven (a ‘tock’). If something goes wrong, it is easier to pinpoint why (and fire the right people, I guess). Variable minimization again.
Finally, this particular set of neurons in my index of a brain lit up again when I hit upon The power of small batches by Eric Ries (an excerpt from his book/movement/religion The Lean Startup). To quickly paraphrase, in a context of extreme uncertainty, working on many features simultaneously is not a good strategy because it does not help us learn when things fail, and does not help us build on successes (again, because we don’t know which one of the many things we did was the turning point). Making small number of changes, validating with users and either pivoting or persevering has more chances to result in project success, particularly when we are building something completely new. Variable minimization.
And there you have it: a bold new (albeit ill-fated) fighter jet project, a model for managing complexity of CPU evolution, and the light at the end of the tunnel for sleep-deprived and overly caffeinated startup founders. In all these stories, a common theme is the importance of keeping the number of variables down so that informed decisions can be made about the course of the project as early as possible.
Now, few of us will start a new fighter jet program or build a new CPU in our spare time, so these examples may seem entertaining but impractical. But they translate quite well into any technology project where something completely new is attempted. And that is exactly what we did in the Rational Jazz Platform project. As we were building the first prototype, we wanted to take the opportunity to reset the technology base, but it was deemed too risky considering that we were just figuring out what we were building in the first place. For this reason, we build the prototype using Jazz Foundation code base we intimately knew (our ‘tick’). Once the demo was finished and presented at IBM Innovate 2013, we reset and are now writing real code on a completely new stack (our ‘tock’).
With the experience of the prototype behind us, I am glad we didn’t go the ‘distinctive, but not too bright’ route of doing both at the same time. If we found out certain features were wrong and are not needed, it would really suck if we spent a lot of time building the stack to support them first.
Jolly good, let’s celebrate with a glass of Glenlivet, neat.
© Dejan Glozic, 2013
Dejan Glozic 