Using Intel's tick-tock strategy in software development

What is Tick-Tock?

Intel's success and dominance in the mid 2000s is sometimes attributed to their famous tick-tock model.

A "tick" is an improvement of the microarchitecture. It usually involves a shrink in the manufacturing process as well as correction of errata discovered since the microarchitecture release.

A "tock" is an overhaul or development of new microarchitecture. This is often rewriting the entire design of the chip, adding new functions and instruction sets.

When I first read about this strategy, I drew parallels with my experience in software development lifecycles. A "tick" sounds exactly like a maintenance release while a "tock" resembled a feature pack.

Would this strategy work for software as well as hardware? It all seems so familiar.

Has it been done before?

A startup-style company I worked at previously, employed this very concept while unaware. In fact, it was not even intentional. But it was not the use of the strategy that was remarkable.

Rather, it was the results.

Every single release was smooth. Months of releases were, pun intended, clockwork.

Now in most cases, a timeline like this is not surprising. Many corporate companies do have periods of trouble-free releases over months.

In this particular company, we had a release once (and occasionally, even twice) a week. To production.

The Research and Development (R&D) department had an interesting approach to software lifecycles. R&D utilized a Lean software development with very short release cycles. In effect, at any one time, multiple teams were working on feature development while a dedicated production support team focused on resolving bugs. Each week, the production support team pushed a new update to production. Occasionally, releases occurred twice in a week if a critical issue arose.

Whenever a development team completed a feature, it was rolled out the following day after integrated testing. Each feature's development cycle was staggered such that for every 4-5 releases, 1 of them was a feature. However the development team that coded the feature for that release, would not take on another for up to 2 weeks after. The team would effectively be "on hold".

The hold provides 2 benefits:

1. The development team that coded the feature is on hand to solely dedicate themselves to related bug fixes. This provides insurance for the release, should something go wrong.
2. Even if there are no issues with the feature, the development team is encouraged to "take it easy" during this hold period. The low intensity period provides an incentive to produce quality code.

Therein lies the cycle: 4-5 weeks of maintenance updates are followed by 2-3 weeks of feature releases and patches or a lull.

Coincidentally, this is very like Intel's tick-tock model.

Will it scale?

The strategy can be employed at scale and at large, corporate companies with longer release cycles. The tenet is that each maintenance update (MR) release should follow a feature pack (FP) so that the development teams rotate between these 2 releases.

When a release is only 4 times a year, the cycle is thus MR, FP, MR, FP.

The strategy brings along other benefits:

• Customers/clients need only update their integration systems for a feature pack (MRs do not add/change existing API). Cautious customers can choose to take the followup maintenance update instead later down the road, while others can take the plunge to gain early adopter advantage.
• Releases are brought together as themes instead of the usual hodge-podge of features, enhancements and bug fixes that litter release notes. We avoid the "Let's throw everything into this release, even the kitchen sink" mentality that often takes hold.
• Time is exclusively allocated for maintenance releases, including fixes and performance improvements.  Features may sell your product, but bugs and sluggishness drive your customers out the door.
• Development is allowed variety in their routines. When rotating our development teams between maintenance releases and feature packs, the differences in intensity of the cycles invigorates them.

Could it work for me?

Bear in mind that the tick-tock strategy is no silver bullet. A convoluted program management style with multiple quality-gates and tiers of decision will subjugate any development model.  A dysfunctional team who hardly gets along, will still fail to get their act together.

A bad app is a bad app. There's no way that the tick-tock strategy can save it.

In the case of the above-mentioned startup-style company, a good team was in place already, with a very compatible program management process in place.

The tick-tock strategy helped hone and focus existing strengths and took it to the next level.

I believe Intel would have found its success with conventional methods since they were already the behemoth in their market space. As of Aug 2016, Intel has a market cap of $168B vs AMD's $6B. These numbers have not changed much since the 2000s. Amazingly, Intel outspends AMD in R&D by an entire order of magnitude as well.

At a time when their rivals were more innovative and on the cusp of turning the tide, Intel developed the tick-tock model. And never looked back since.

Every accomplishment starts with the decision to try.
- John F. Kennedy