Who cares about inefficient code

At the risk of stirring up a hornets nest, I'm getting really tired of the naysayers who quickly play the "it's not as efficient as hand-crafted code" card when a new, high-level programming or design technique comes along. They just don't seem to get it that the question of 'efficiency' extends well beyond the run time of the application. In the real world of commercial pressures, making successful products is not just about the performance of the end product. It's also about your ability to develop, deploy and maintain that product within the window of opportunity given to you by the market.

This little rant of mine was provoked again after I read a recent FPGA Journal article 'Drag and Drop vs HDL?' by Dick Selwood. It was a well-written and informative article about National Instrument's continued push into FPGA design with their drag and drop design environment. But all three reader comments (as of today) focus around the efficiency of the code produced by GUI based design approaches. Now come on guys. Surely you can try a bit harder. Of course hand crafted code is going to be more efficient than GUI-based stuff. But that only matters when it matters! To write off the whole GUI-based approach on account of the few situations when it isn't suitable is way to short-sighted. And it's not like NI is taking away the ability to use hand-crafted code. They are simply giving you the choice.

The real problem with the "it's not as efficient as hand crafted code" argument is that although it sounds rational, it places us in a very dangerous position of being dismissive of the whole technique without giving further thought to whether that technique will be disruptive. If you ever get the chance to read "The Innovator's Dilemma" by Clayton M. Christensen then I highly recommend you do. It gives some really strong reasons why it can be suicidal to ignore new technologies on the basis of how well they fit current market demands. Technology doesn't stand still. It continues to push on at a break neck pace. If we dismiss a technology today because it appears to be inefficient compared with established techniques, we run the risk of being blind-sided when technological advances suddenly make the inefficiencies irrelevant. By that time, it is too late to reposition ourselves around the new way of doing things. As the book puts it, the real question is not about efficiency, it is about how disruptive the 'new thing' will be.

So here are my rules:

1) If something looks slow, technology will make it fast.

2) If a new design technique raises the abstraction level, gets you to market faster, or allows broader access to growth technologies (i.e. disruptive), it will supplant other techniques.

3) There will always be a need for hand-crafted solutions. But the proportion of products that must be hand-crafted will decrease.

The difference between Vias and Pads

A recent post on one of Altium's forums related to the fundamental difference between pads and vias. So because I thought it was an interesting question, I figured it was worth posting a blog entry about it.

Pads are the connection point between copper on the PCB and leads on the component. They are a common part of component footprints and they can be through hole or surface mount. When they are through hole, they are virtually always drilled completely through the board. When they are surface mount, they only exist on either the top or bottom layer. Pads can have virtually any arbitrary shape however round, rectangular, and rounded rectangular are most common.

Vias, on the other hand, are the means by which an electrical connection is routed between two layers. As such, they are part of the track net and not usually tied to the component footprint. They are always drilled and always round. The depth of a via can vary depending on whether it needs to pass between the outside layers of the PCB, an outside and inside layer (blind), or two inside layers (buried).

So the big question is, "Are these two primitives similar enough to be merged as one?"
The short answer is No. And the reasons are multiple:
1) Pads make their connection to component leads by being soldered. This means that the properties of the pad must have consideration for the soldering process being used. Solder mask pullback, pad surfacing, size and shape are all dictated by the soldering process and the physical properties of the component lead being connected.
2) Pads need to support multiple sizes and shapes due to both the properties of the leads of components connected to them, and any heatsinking effects needed as part of the component's cooling.
3) The pads of low pin count surface mount components need to be thermally balanced to avoid any ill effects caused by different cooling rates. For instance, a pad on one end of a two lead component (such as a resistor) that cools faster then the pad at the other end can cause the component to stand on its head (tombstone) as the solder contracts.
4) Unless you are dealing with embedded passives (i.e. components that are placed within the layers of the PCB), it makes little sense to have buried pads. Blind pads could be argued for some leaded components but that would make the board very dependant on very accurate lead lengths being maintained by the component vendor. This is probably an unnecessary risk as component leads that are too long will cause the components to stand off from the PCB. In some instances this may be desirable but I suspect it would be more hassle than it's worth.
5) Pads must have a designation to indicate how component pins and pads must be aligned.
6) The primary conduction path of a via is through the hole barrel. The copper donut area on top and bottom of the via is simply there to provide a solid connection between the hole barrel and the top / bottom connecting tracks. Without this, the connecting track could be torn off when the via barrel is drilled during manufacture.
7) Because vias don't require solder to fulfill their purpose, vias can be tented (covered with solder mask) to ensure that no copper is exposed to the outside world. This limits the risk of oxidisation of the via copper.
8) Vias offer a path between layers and so it is meaningless to use anything other than round, donut-shaped entry/exit points.
9) Vias need not have any designation since they are unreleated to components. However some form of unique ID would be helpful when devising design rules intended only for specific vias (of specific nets).

So in summary, Vias and Pads might appear similar but their functions are quite separate. And in my view, they should remain as separate primitives. Comments?