feature article
Subscribe Now

The 90 Percent Trap

Surviving the Best Day of our Careers

The VP was obviously impressed. In fact, “blown away” wouldn’t have been overstating it. The demo had gone perfectly, and even when he’d asked questions that took us off script, we were able to show what he wanted to see. His excitement was palpable. I knew before he walked out the door that we’d get what we wanted.

Funding.

Our little team, made up of some of the most talented software engineers I’d ever met, had been working 12-14 hours per day for the past two weeks to get this demo ready. In reality, a lot of it was smoke and mirrors. We’d cobbled together TCL scripts to fill in holes in our system where development hadn’t even been started yet. There were some places where the “values” that showed in the GUI were hard-coded. But, behind the scenes, the engine was actually running and doing its job. Databases were being written and read. Actual output files were being generated. It was REAL.

Or, probably, at least 90% real. 

In EDA, developing a new tool is the least expensive part. Give me six great engineers (bonus if at least two of them are recent PhDs in the area of interest), a roomful of computer hardware, and one uninterrupted year, and I’ll give you a kinda’ usable new EDA tool that does whatever you want. In the world of developing new leading-edge technology products, that’s about as cheap as you’re gonna get.

That fact is what, in the old days, brought venture capitalists flocking to EDA. Tiny investments, it seemed, could reap huge rewards relatively quickly.

The problem is, that one-year-baked EDA tool (and this extends beyond EDA to most new software products, actually) isn’t ready to sell broadly. (SPOILER ALERT: It won’t be to that stage for at least five more years, if ever.) After one year, you generally have something that is ready to expose to one or two beta customers – each supported by a dedicated applications engineer who is an expert in avoiding the numerous known holes in the new tool’s capability. Those first two “customers” are sacrificial, by the way. They’re generally doomed to leave the party disappointed. No matter how many designs you’ve run through your new tool back in the regression lab, it’s pretty much guaranteed that the very first “real” customer design will break it. And, the second design as well. And, the third.

This well-known phenomenon is a real problem for large, established EDA companies. It’s really inexpensive to send of a half-dozen engineers off for a year to develop a new product that could eventually bring in hundreds of millions in revenue. But what you have after that one year isn’t something you want to risk showing to your valuable customers. In fact, your sales team, who works with your top multi-national systems-house customers, won’t let new, unproven products anywhere near their commission cows. New products suck up valuable AE resources and risk alienating key influencers at the customer site.

As a result, there is a low bar for EDA companies to start new products, but a pretty high bar for them to actually deliver them to market (when the real costs and risks begin). Getting a pilot project funded internally is pretty easy. Getting it past the rough proof-of-concept stage is exponentially harder. That’s why our demo was so important that day. We needed to convince our VP that our project was one of the few worth continuing past the original proof-of-concept demo. 

This is why most EDA innovation has historically been done in small startups. Software startups are cheap, and they can get something ready to throw at customers pretty quickly. If the customer is unhappy, only the startup’s reputation is damaged. Make several real customers happy and get your product past the toddler stage, though, and you’re a target for acquisition by one of the big companies – one who could actually afford to market, sell, and support your product globally. 

But some EDA innovation does take place inside big EDA companies, and the process for making that happen typically involves an early executive demo. That’s the point where fates pivot on a dime. That’s where the go/no-go decision is usually made about the continuation of the project. And it isn’t always clear whether, as an engineer, you’re better off in the long run if demo day succeeds or fails.

As every software engineer knows, getting a demo to look like the thing you’re building is a pretty quick and easy task. Really, you’re just mocking up a UI and putting some basic level of functionality behind it. Unfortunately, when you do that, you create a management phenomenon I call the “90% Trap.” No matter how much disclaimer you present to an executive, seeing a plausible demo gives them an incredible (and unjustified) sense of success. The product looks 90% done. Sure, there may be a few things to tidy up here and there, but obviously the thing is real and almost working. Right? Right?

As every software engineer also knows, that point where the demo looks 90% done is typically the point where the actual software development is about 1% done. By presenting the demo to management, you have just created a chasm that will most likely never be closed. At that moment, you become 89% behind schedule (more or less, depending on how you do the math). If the demo magically appeared after one month of development, management will be quietly stressed to know that three months later, the demo looks exactly the same. In fact, it might even look worse as reality has set in and putting “real code” behind some of the features that were only mockups has led to instability, poor performance, re-thinking of the user experience, and countless other issues. As the reality of software development and testing slowly sets in, It just goes downhill from there.

That first demo day is generally the best day in the entire product life cycle for a software development team. On that day, there are no customer bugs. On that day, they are perceived to be FAR ahead of schedule. On that day they are heroes.

It will never happen again.

From demo day forward, management will be disappointed. Development will take longer than forecast. Costs will be higher. Features will be less flashy. Early customers will be unhappy. Sales people will be disillusioned. Bugs will pile up. Team members will leave. Sure, there will be some good days as well as bad days. Eventually, if the team persists and overcomes the adversity of the initial development process (which can extend into many years), there may be the long-lasting satisfaction of real success – where the fruits of your efforts are enabling engineering customers around the world to do their innovation.

But the grizzled and wizened engineering team that arrives at that day bears little resemblance to the bright-eyed optimists who gave that original demo. Sunrise and sunset can be similarly beautiful, but they are horizons apart – separated by the experience of a day.

 

 

Leave a Reply

featured blogs
Mar 31, 2023
Learn how (and why) the semiconductor industry is moving towards chiplet-enabled multi-die systems in our research piece in MIT's Technology Review Insights. The post An Industry-Wide Look at the Move Toward Multi-Die Systems appeared first on New Horizons for Chip Design....
Mar 31, 2023
The Verisium Debug platform is optimized for scalability, supporting debugging of simulation runs and emulation, where support for loading large source files and handling huge amounts of probe data is a must. Join this free Cadence Training Webinar to learn how to automate yo...
Mar 30, 2023
Are you in desperate need of a program manager to instigate a new project or rescue an existing project that is spiraling out of control?...

featured video

First CXL 2.0 IP Interoperability Demo with Compliance Tests

Sponsored by Synopsys

In this video, Sr. R&D Engineer Rehan Iqbal, will guide you through Synopsys CXL IP passing compliance tests and demonstrating our seamless interoperability with Teladyne LeCroy Z516 Exerciser. This first-of-its-kind interoperability demo is a testament to Synopsys' commitment to delivering reliable IP solutions.

Learn more about Synopsys CXL here

featured chalk talk

ActiveCiPS™: Configurable Intelligent Power Management Solutions
Sponsored by Mouser Electronics and Qorvo
Programmable power management can not only help us manage our power systems but it can also have size, weight, and cost benefits as well. In this episode of Chalk Talk, Amelia Dalton chats with Yael Coleman from Qorvo about the system-wide benefits of configurable power management solutions. They investigate the programmable features of the ActiveCips configurable intelligent power management solutions and review how these solutions can help you balance weight, size, power and cost in your next design.
Jul 19, 2022
31,297 views