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
Dec 6, 2023
Optimizing a silicon chip at the system level is crucial in achieving peak performance, efficiency, and system reliability. As Moore's Law faces diminishing returns, simply transitioning to the latest process node no longer guarantees substantial power, performance, or c...
Dec 6, 2023
Explore standards development and functional safety requirements with Jyotika Athavale, IEEE senior member and Senior Director of Silicon Lifecycle Management.The post Q&A With Jyotika Athavale, IEEE Champion, on Advancing Standards Development Worldwide appeared first ...
Nov 6, 2023
Suffice it to say that everyone and everything in these images was shot in-camera underwater, and that the results truly are haunting....

featured video

Dramatically Improve PPA and Productivity with Generative AI

Sponsored by Cadence Design Systems

Discover how you can quickly optimize flows for many blocks concurrently and use that knowledge for your next design. The Cadence Cerebrus Intelligent Chip Explorer is a revolutionary, AI-driven, automated approach to chip design flow optimization. Block engineers specify the design goals, and generative AI features within Cadence Cerebrus Explorer will intelligently optimize the design to meet the power, performance, and area (PPA) goals in a completely automated way.

Click here for more information

featured paper

Power and Performance Analysis of FIR Filters and FFTs on Intel Agilex® 7 FPGAs

Sponsored by Intel

Learn about the Future of Intel Programmable Solutions Group at intel.com/leap. The power and performance efficiency of digital signal processing (DSP) workloads play a significant role in the evolution of modern-day technology. Compare benchmarks of finite impulse response (FIR) filters and fast Fourier transform (FFT) designs on Intel Agilex® 7 FPGAs to publicly available results from AMD’s Versal* FPGAs and artificial intelligence engines.

Read more

featured chalk talk

Peltier Modules
Do you need precise temperature control? Does your application need to be cooled below ambient temperature? If you answered yes to either of these questions, a peltier module may be the best solution for you. In this episode of Chalk Talk, Amelia Dalton chats with Rex Hallock from CUI Devices about the limitations and unique benefits of peltier modules, how CUI Devices’ arcTEC™ structure can make a big difference when it comes to thermal stress and fatigue of peltier modules, and how you can get started using a peltier module in your next design.
Jan 3, 2023
39,484 views