feature article
Subscribe Now

A Mile in Their Shoes

Altium's Engineering Empathy

Much of Nick Martin’s day is like the typical workday of any large company CEO. Nick attends meetings, talks with the press and analysts about the company’s products and performance, works to drive corporate and product strategy, and even stops to eat occasionally. Where Nick’s path diverges sharply from the norm is that you just might also find him sitting in front of a multi-monitor machine running Altium Designer (the company’s flagship, end-to-end electronic design software package), trying to finish up the last details of a board he’s designing. This is not just some canned, pre-scripted demonstration to prove that the CEO is in touch with technology. This is an actual board design that Altium plans to sell in production – the NanoBoard-NB2.

At some level, the business of running any big international corporation is largely the same. In high technology, however, the mundanity of macromanaging a large organization often insulates executives from the actual technology challenges faced by both their customers and their own engineers. At Altium, they do things a little differently. Nick is an electronics engineer at heart, and his company provides design automation software aimed at helping the average working engineer get his job done better and faster. In order to accomplish that goal, Nick feels that everyone working to deliver that capability, himself included, needs to walk a mile in the shoes of the engineer using their products. That is why, when the company needed a new development board to go with the latest version of Altium Designer, they chose to do the design themselves, using their own software.

One of the classic problems faced by users of electronic design automation software is that the developers of the software are, by necessity, software engineers. They generally try to achieve some level of empathy for the hardware designer who will ultimately be using the product they create, but at the end of the day, these software folks typically have very little idea how the hardware engineer works, and the products show it. Altium took advantage of the fact that it was developing both a new circuit board and software to design circuit boards to maximize their customer empathy. Engineers working on the software were tasked with using their own software to design critical parts of the NanoBoard-NB2 – and on a tight schedule. The NanoBoard-NB2 and the new software were to be debuted at the Embedded Systems conference, and the team had very little time to get them ready for prime-time.

In the world of software products, most changes and improvements come as a result of bug reports filed by customers, designated testers, or even by development engineers themselves. For any reasonably complex software system with more than about two serious users, the number of bug reports and change requests will far outpace the fix rate of the development engineers, so a priority system is required to help decide which problems should be addressed first. In most of these systems, “serious” or “critical” problems like crashes, database corruptions, and wrong output get the most attention, followed down the scale to less and less severe problems. While such a system makes sense on paper, it overlooks an important aspect of creating productive software – most of the things that make the difference in productivity (like accomplishing a particular repetitive task in two clicks instead of twelve) never surface as “critical” bugs and so never get addressed. Even obscure crashes that almost no real customer will ever see are often given priority over massive productivity problems that will affect every single user of the tool.

By turning their engineers into users with a critical need to get a real design project finished, Altium turned the old priority system on its head – or at least on its side. If the software was making a repetitive task difficult or slow, the engineer that was using the software to finish his board would be sure that the problem got immediate attention. Evolution of the product was forced toward the practical. Endless software engineer debates about which features might or might not be useful to some hypothetical customer were replaced by hands-on practical knowledge that can come only from trying to use the tool yourself, on a real project, with severe schedule pressure. Clearly, after this process, customers of Altium’s software will be much less likely to utter the familiar EDA-customer phrase, “Nobody who has ever designed a board would make software work this way.”

This “eat your own dogfood” philosophy is not new at Altium. “Our overall idea is that anyone directly involved in developing our software will have to do a project,” observes Jason Hingston, Senior Software Architect at Altium. Members of the team worked on various aspects of the NanoBoard system, with Jason tackling the Audio/Video plug-in board and Nick Martin himself taking on the main board. The engineering-centric approach has a clear impact on the company culture, and you can hear it when talking with the engineers. “We know we’re kinda’ engineering geeks, but we enjoy it,” comments one of the developers. Even the CFO got in on the action, running the software himself and becoming a frequent poster on the developers’ forum. In most companies, the probability of the CFO running an EDA tool are exactly – wait, we need a spreadsheet to figure that out.

Also common in technology companies is a disconnect between senior management and the experts actually building the products. The usual result: engineers spending hours developing PowerPoint presentations (usually bad ones), trying to “dumb-down” critical aspects of the technology so that executives can glean some modicum of understanding of the technical tradeoffs being made in order to assess the potential business impact of those technology-driven decisions. Did we mention yet that Altium’s CEO designed the main circuit board himself – using a beta version of the company’s own software? It’s difficult to imagine a much more compelling imperative to fix a software glitch in a design tool than having your own CEO be stuck on a board design that he is trying to complete on a tight deadline. At one point, unhappy that some aspect of polygon manipulation in the tool was not to his liking, Martin reportedly declared, “I’m not gonna’ continue until you fix this.”

How much pressure was there? “We had about six weeks before the conference to get the board finished,” says Ben Wells, Altium’s Technology Center Director and leader of the Altium Designer team in Sydney, Australia. “We had to get the board right on the first shot. A re-spin was not available.” That pressure kept the team on-task – both in their board development efforts and in their efforts to fine-tune Altium Designer to better satisfy their own needs. “We found that tiny things could make a huge difference,” Wells continues, “like situations where you press <Enter> and the focus moves, preventing you from repeating the operation smoothly.” That kind of feedback usually isn’t pulled into an EDA tool until it is in customers’ hands, and then the limitations of the bug priority matrix often forestall even small changes that could make a big difference. Sometimes, aware of the priority system, customers don’t even bother reporting such bugs, jaded with the idea that they’ll never get attention anyway.

Often, however, a high-productivity fix can be put in with almost no effort if it makes it up the priority stack to get some engineering attention. “There is no relationship between the difficulty of implementing a bug fix and the importance of that fix to the user,” Wells observes. As a result, the team was able to quickly streamline the software by making smart tradeoffs between user impact and coding effort.

What were the results of the project and the approach? The Nanoboard-NB2 was operating smoothly on the show floor at the conference, so the hardware project was clearly successful. “We had only one glitch to work out, and it was solved by the flexibility of the FPGA,” Wells explains. “We didn’t have to make any changes to the board itself.”

And, what about the impact on the design tool software? “The 6.3 release has been very well received by customers,” observes Rob Irwin, Product Marketing Manager at Altium. “The customer feedback we’ve gotten so far says it’s the most practical and usable release we’ve done yet.” Given the company’s novel but common sense approach, that is not a big surprise.

Leave a Reply

A Mile in Their Shoes

Altium’s Engineering Empathy

At some level, the business of running any big international corporation is largely the same. In high technology, however, the mundanity of macromanaging a large organization often insulates executives from the actual technology challenges faced by both their customers and their own engineers. At Altium, they do things a little differently. Nick is an electronics engineer at heart, and his company provides design automation software aimed at helping the average working engineer get his job done better and faster. In order to accomplish that goal, Nick feels that everyone working to deliver that capability, himself included, needs to walk a mile in the shoes of the engineer using their products. That is why, when the company needed a new development board to go with the latest version of Altium Designer, they chose to do the design themselves, using their own software.

One of the classic problems faced by users of electronic design automation software is that the developers of the software are, by necessity, software engineers. They generally try to achieve some level of empathy for the hardware designer who will ultimately be using the product they create, but at the end of the day, these software folks typically have very little idea how the hardware engineer works, and the products show it. Altium took advantage of the fact that it was developing both a new circuit board and software to design circuit boards to maximize their customer empathy. Engineers working on the software were tasked with using their own software to design critical parts of the NanoBoard-NB2 – and on a tight schedule. The NanoBoard-NB2 and the new software were to be debuted at the Embedded Systems conference, and the team had very little time to get them ready for prime-time.

In the world of software products, most changes and improvements come as a result of bug reports filed by customers, designated testers, or even by development engineers themselves. For any reasonably complex software system with more than about two serious users, the number of bug reports and change requests will far outpace the fix rate of the development engineers, so a priority system is required to help decide which problems should be addressed first. In most of these systems, “serious” or “critical” problems like crashes, database corruptions, and wrong output get the most attention, followed down the scale to less and less severe problems. While such a system makes sense on paper, it overlooks an important aspect of creating productive software – most of the things that make the difference in productivity (like accomplishing a particular repetitive task in two clicks instead of twelve) never surface as “critical” bugs and so never get addressed. Even obscure crashes that almost no real customer will ever see are often given priority over massive productivity problems that will affect every single user of the tool.

By turning their engineers into users with a critical need to get a real design project finished, Altium turned the old priority system on its head – or at least on its side. If the software was making a repetitive task difficult or slow, the engineer that was using the software to finish his board would be sure that the problem got immediate attention. Evolution of the product was forced toward the practical. Endless software engineer debates about which features might or might not be useful to some hypothetical customer were replaced by hands-on practical knowledge that can come only from trying to use the tool yourself, on a real project, with severe schedule pressure. Clearly, after this process, customers of Altium’s software will be much less likely to utter the familiar EDA-customer phrase, “Nobody who has ever designed a board would make software work this way.”

This “eat your own dogfood” philosophy is not new at Altium. “Our overall idea is that anyone directly involved in developing our software will have to do a project,” observes Jason Hingston, Senior Software Architect at Altium. Members of the team worked on various aspects of the NanoBoard system, with Jason tackling the Audio/Video plug-in board and Nick Martin himself taking on the main board. The engineering-centric approach has a clear impact on the company culture, and you can hear it when talking with the engineers. “We know we’re kinda’ engineering geeks, but we enjoy it,” comments one of the developers. Even the CFO got in on the action, running the software himself and becoming a frequent poster on the developers’ forum. In most companies, the probability of the CFO running an EDA tool are exactly – wait, we need a spreadsheet to figure that out.

Also common in technology companies is a disconnect between senior management and the experts actually building the products. The usual result: engineers spending hours developing PowerPoint presentations (usually bad ones), trying to “dumb-down” critical aspects of the technology so that executives can glean some modicum of understanding of the technical tradeoffs being made in order to assess the potential business impact of those technology-driven decisions. Did we mention yet that Altium’s CEO designed the main circuit board himself – using a beta version of the company’s own software? It’s difficult to imagine a much more compelling imperative to fix a software glitch in a design tool than having your own CEO be stuck on a board design that he is trying to complete on a tight deadline. At one point, unhappy that some aspect of polygon manipulation in the tool was not to his liking, Martin reportedly declared, “I’m not gonna’ continue until you fix this.”

How much pressure was there? “We had about six weeks before the conference to get the board finished,” says Ben Wells, Altium’s Technology Center Director and leader of the Altium Designer team in Sydney, Australia. “We had to get the board right on the first shot. A re-spin was not available.” That pressure kept the team on-task – both in their board development efforts and in their efforts to fine-tune Altium Designer to better satisfy their own needs. “We found that tiny things could make a huge difference,” Wells continues, “like situations where you press <Enter> and the focus moves, preventing you from repeating the operation smoothly.” That kind of feedback usually isn’t pulled into an EDA tool until it is in customers’ hands, and then the limitations of the bug priority matrix often forestall even small changes that could make a big difference. Sometimes, aware of the priority system, customers don’t even bother reporting such bugs, jaded with the idea that they’ll never get attention anyway.

Often, however, a high-productivity fix can be put in with almost no effort if it makes it up the priority stack to get some engineering attention. “There is no relationship between the difficulty of implementing a bug fix and the importance of that fix to the user,” Wells observes. As a result, the team was able to quickly streamline the software by making smart tradeoffs between user impact and coding effort.

What were the results of the project and the approach? The Nanoboard-NB2 was operating smoothly on the show floor at the conference, so the hardware project was clearly successful. “We had only one glitch to work out, and it was solved by the flexibility of the FPGA,” Wells explains. “We didn’t have to make any changes to the board itself.”

And, what about the impact on the design tool software? “The 6.3 release has been very well received by customers,” observes Rob Irwin, Product Marketing Manager at Altium. “The customer feedback we’ve gotten so far says it’s the most practical and usable release we’ve done yet.” Given the company’s novel but common sense approach, that is not a big surprise.

Leave a Reply

featured blogs
Oct 22, 2020
WARNING: If you read this blog and visit the featured site, Max'€™s Cool Beans will accept no responsibility for the countless hours you may fritter away....
Oct 22, 2020
Cadence ® Spectre ® AMS Designer is a high-performance mixed-signal simulation system. The ability to use multiple engines and drive from a variety of platforms enables you to "rev... [[ Click on the title to access the full blog on the Cadence Community site....
Oct 20, 2020
In 2020, mobile traffic has skyrocketed everywhere as our planet battles a pandemic. Samtec.com saw nearly double the mobile traffic in the first two quarters than it normally sees. While these levels have dropped off from their peaks in the spring, they have not returned to ...
Oct 16, 2020
[From the last episode: We put together many of the ideas we'€™ve been describing to show the basics of how in-memory compute works.] I'€™m going to take a sec for some commentary before we continue with the last few steps of in-memory compute. The whole point of this web...

featured video

Demo: Low-Power Machine Learning Inference with DesignWare ARC EM9D Processor IP

Sponsored by Synopsys

Applications that require sensing on a continuous basis are always on and often battery operated. In this video, the low-power ARC EM9D Processors run a handwriting character recognition neural network graph to infer the letter that is written.

Click here for more information about DesignWare ARC EM9D / EM11D Processors

featured paper

Designing highly efficient, powerful and fast EV charging stations

Sponsored by Texas Instruments

Scaling the necessary power for fast EV charging stations can be challenging. One solution is to use modular power converters stacked in parallel. Learn more in our technical article.

Click here to download the technical article

Featured Chalk Talk

Thermal Management Solutions

Sponsored by Mouser Electronics and Panasonic

With shrinking form factors, tighter power budgets, and higher performance, thermal management can be a challenge in today’s designs. It might be time to bust out the thermal grease to help conduct away some of that excess heat. But, before you grab that tube, check out this episode of Chalk Talk where Amelia Dalton chats with Len Metzger of Panasonic about the details, drawbacks, and design considerations when using thermal grease - and its alternatives.

Click here for more information about Panasonic Thermal Management Solutions