A History of (Premature) Optimization

I saw some material shared from DVCon Europe last month that suggested a competition brewing between shift left and agile in semiconductor development. As someone who’s been following shift left writing and been advocating for agile development, this kind of comparison is more than a little odd to see. It’s a comparison between two as yet amorphous development strategies, neither of which is well defined nor understood.

But while it was odd to see, the comparison is not completely unexpected. In my opinion, the semiconductor industry has made a habit of prematurely selecting and optimizing tools and methods around unproven technologies. For example…

In my relatively short 15 years of functional verification, I’ve seen development tools and flow optimized several times to support unproven strategies. It happened in a big way when constrained random verification was declared cutting edge over directed testing; again when EDA rallied around SystemVerilog to brush aside e, C and C++ as well as new possibilities like Python; yet again with the consolidation of UVM and dismissal of VMM and OVM. (I feel like the next premature optimization may involve , though that’s just a guess!)

The pattern in each of these examples is similar:

• create a false dichotomy of technology/method A vs. technology/method B
• declare a marketing competition
• select a winner
• standardize the winner and/or call it “best practice”
• optimize development tools to support the winner before it has been proven in the field
• squeeze the industry into a one-size-fits-all solution
• marginalize those who resist

It might read a little harsh, but that’s history as I see it. Now to the false dichotomy of shift left and agile hardware development…

Shift left, from what I read, is a strategy for cutting time-to-market for the devices we build. Teams foster concurrency in development process (i.e. shift left in the project schedule); doing everything sooner, ideally simultaneously, results in a shortened schedule.

It’s hard to argue with the idea of shift left because it seems like a very logical way to address the schedule overruns common in semiconductor development. It’s in the details though where things get a little hazy. How a team shifts left differs depending on who you talk to (and, unfortunately, how they benefit). Is it software or verification that’s shifting left? How are they shifting? The tools they use? Who and what aren’t shifting? Why?

The diversity in shift left proposals suggests to me the whole concept is still up for debate. I’ve heard more than one person describe the debate as a weakness of the strategy and that consolidation through a standard tool flow is the logical next step. A standard tool flow, of course, would satisfy our natural tendency toward premature optimization. Especially if it were to arrive through industry collaboration, a standard tool flow would no doubt be perceived as a win.

I think reducing the idea of shift left to a standard tool flow would be a shame. To state the obvious, there’s more than one way to optimize for time-to-market. For that reason I see the various definitions of shift left as a strength. Having multiple tool flows gives development teams the option of choosing based on need. If out of experience we find a shift left winner capable of dragging everyone to market faster, great! If not, who cares, as long as teams have what they need to shift left as they see fit.

Which takes us to agile hardware development. Agile is another area where a diverse set of solutions is not only probable, it’s guaranteed. At it’s core, agile is a mindset that promotes responsiveness to market need. To support that responsiveness, software history has exposed many different approaches. Each approach has naturally been tailored to a team’s specific set of circumstances. How a team increases their responsiveness and how far they go with it is entirely up to them.

There are famous software examples of teams embracing agile. Three such examples come from Spotify, Menlo Innovations and Pivotal. These organizations built their own strategy for responsiveness, chose the tactics that fit the strategy and continually optimize the strategy and tactics to increase their responsiveness. Importantly, the tactics they use may or may not be industry standard and the culture they’ve created to support the strategy is distinctly homegrown. In short, agile was not prescribed for these teams and their success is certainly not the result of industry optimization.

No surprise, there are many examples of failed agile teams. I’m assuming every failed attempt came from a team that also had their own interpretation of responsiveness and strategy–or non-strategy–for attaining it. With wild variability in success rates, it should be obvious that simply choosing to be agile plays a near insignificant part in determining outcome. Likewise, announcing a shift left is entirely meaningless. It’s everything that happens after these decisions that counts.

To wrap up this theoretical discussion, let’s return to our habits of creating false dichotomies and premature optimization. I’d argue some industry best practices–like constrained random verification, SystemVerilog and UVM–are optimizations created at the expense of innovation that arose from false competition. Shift left and agile hardware development are new chances to break the cycle of premature optimization. Regardless of whether you see shift left as a revolutionary industry trend or a vacuous mission statement, there is potential provided we keep our options open. Likewise for agile, maybe we improve the way software teams have improved, maybe we don’t. Either way, prematurely optimizing tools and flow destroys potential.

When it comes to shift left and agile hardware, don’t bother picking sides because there is no competition, just potential. What comes of it will be decided by the teams that use them, not the people that standardize them.