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.
