This is the fourth article in a series about my career experiences in the PCB industry. The first three articles focused on my start as a designer and the beginnings of my PCB design firm, Computer Circuits.

As business grew, I became more and more intrigued by the software. Every designer believes that the software they are using can be improved, and we all have many ideas on what should be done. In 1982, Racal-Redac showed interest in having me work for them to improve their Maxi software. I didn't want to close my service bureau, so we worked out a way for me to do both. Mike Marsh, the president at Redac, made this possible, and my journey into the software side of PCB design began.

At Redac, I began as the Director of PCB Products, where I managed the development, test, and marketing of Maxi. After a couple of months, I came to understand that the viewpoints of a designer and a software vendor were surprisingly different. As a designer, I believe the important capabilities are those that simplify the design process and enable me to quickly and easily complete the task, all within the context of my own little world of idiosyncrasies and preferences. Most designers, including me, are intensely biased about what the software should do, as well as how it is done. Although software vendors understand how eccentric designers can be, their challenges are different, and their goal is to do more than just appease the designer.

In the world of software creation, it is not possible to satisfy everyone. Trying to support every technology sector, every competitive capability, every fabrication method, and every would-be-nice feature, will only result in mediocrity. When trying to satisfy everyone, the result is usually a bloated product that satisfies few, if any. Like any business, success is attained by focusing on the right solutions in the right market segments, aligned with the company’s expertise. The hard part is figuring out what the "right" things are; unfortunately, the right thing for the designer isn’t always aligned with the right thing for the software vendor.

Redac’s primary reason for moving away from Maxi was because its 16-bit architecture and limited memory capacity could not readily support new requirements and higher design limits. The good news was that at the same time, the computer hardware industry was growing quickly and many new computer systems were becoming available. The software industry took advantage of this. The DEC MicroVAX enabled Redac to abandon the limits of the PDP-11 series and move to a newer operating system. The hard part was, this also entailed rewriting most of the software.

 

Figure 1  PDP-11/34 used for Maxi software

 

I read a story many years ago about an intriguing approach to software development, in particular, simulations. Paraphrasing:

A scientist needed to do a computer simulation that would take five years to complete using the current hardware. Knowing that hardware performance was increasing dramatically, a decision was made to delay the start of the simulation for two years, with the expectation that the simulation would only take one year with the new hardware. Thus, the simulation would be completed in a total of only three years instead of five.

This story is pertinent because when developing design software, slow performance is often a problem, and doing nothing while waiting for the hardware to become faster can be a valid consideration. Of course, if the performance can be improved through relatively minor software enhancements, it makes sense to do so. However, if it requires a rewrite of the code, waiting for the faster hardware may be the better alternative. However, there is a third and riskier approach with tremendous potential: while waiting for the hardware to improve, rewrite the software as well.

Redac began creating their next generation software in 1982, which was eventually named Visula. It was a total rewrite, based on 32-bit Unix hardware. Although I was managing Maxi in maintenance mode, I also participated in the Visula project. One important aspect of doing a rewrite is to make good decisions about keeping or discarding functionality from the previous generation. We quickly learned that users grow attached to certain features and are upset when they are removed or radically changed. This was a clear case of finding the right balance to keep our customers content.

My role in the rewrite was primarily writing UI specs. I also worked with the development team, testing and giving feedback on new autorouting technology which was eventually released as the Bloodhound Router. I was fortunate to work with the late Alan Finch during this time, a true genius and gentleman. Alan desired software that would emulate how a designer would approach routing problems. After each pass of the autorouter, his software would analyze the results; using that data, it would make decisions on how to improve the next pass. It was more than just changing the costs to get a higher completion rate. It would also consider things that a designer would be concerned about, such as eliminating unnecessary vias, removing excessive meandering, and rerouting sections to make them more efficient.

This perspective of finding solutions that reflect what a designer would do continues to influence my approach to software functionality. Alan’s legacy in our industry is mainly his gridless routing technology – and, outstanding personal character. I would add that his desire to create algorithms that emulate the designer continues to have a significant impact on PCB design software today.

In this, my first venture into PCB design software, I truly loved the creative aspects of the work. However, it presented me with a dilemma: How could I continue to give enough attention to Computer Circuits, and at the same time, fully immerse myself in the software side? Stay tuned.

Related articles:

 

Charles Pfeil is a Senior Product Manager at Altium, working on definition of their products with a primary focus on routing tools.