Engineering is a beautiful blend of science and art, discovery and creation, discipline and imagination.
For those who are pure scientists, there is only discovery. The truth is out there, and they seek merely to uncover it. Scientists do not create science. Mathematicians do not make math. These practitioners simply unearth the treasures of truth that were there all along, bringing them to light and casting them in a new understanding.
For those who are artists, there is only creation. Artists seek to communicate ideas and emotions by creating that which has never existed before – either in concept or in realization. Art is about newness and innovation. Art is about humanity and expression.
As engineers, we study math and science. They are our tools – the palettes from which we select the fundamental elements of our creations. Sometimes, engineering school can make it seem like it all ends there, in a world where design is a rote process consisting of gathering all the proper inputs, turning the crank, and popping out a properly-sized solution. In reality, nothing could be farther from the truth.
We fall into this fallacy because much of engineering school is spent walking in the shoes of those who have gone before. We learn to re-create the solutions of the past so that we have the wisdom and experience to engineer the innovations of the future. This is not unique to engineers, however. Artists also traverse the history of their predecessors in their journey to extend the road to new places. One cannot confidently make a new thing unless one knows already what is old.
Real engineering, like real art, is about creating new things. However, it is only after we apply the lessons and ideas from the past that we stand a chance of truly innovating. Otherwise, the world would have only wheels. Plugging two new values into Ohm’s Law in order to calculate a third is not engineering.
In both art and engineering, we are paving roads to infinity. We learn by traveling to the end of what has already been done, and then we make our mark by extending the path in a new and inspired direction. It is tempting to work only on the part of the road that is already known – adding layers of pavement, extra guardrails, better signage, or a few more lanes. If we want to remain relevant as engineers, however, we need to be working near the end of the existing road. That is where we’ll discover new places and see new things.
In electronic design, we abstract. Once the first person cross-connected a couple of NAND gates to make a flip-flop, that work was done. We could abstract our way up the chain using flip-flops as building blocks. Once we had registers, adders, multipliers – people could take those as given and abstract up again, creating more complex structures on the work of others. Today, we embody much of that work as “IP” and assemble piles of it into new and interesting configurations. Need USB in your design? Grab some IP and go. Want to verify it? There is IP for that too. A few years ago, designing your own USB interface was an interesting engineering challenge. Today, that road is paved – time to move on along.
At some point, we also abstracted our way from hardware to software. With the commoditization of programmable hardware like processor IP and FPGAs, cutting-edge electronic design work could be elevated to the level of programming. We have literally abstracted pure hardware engineers out of a job. At a very high level, we almost don’t need to design hardware anymore. We could create a plethora of interesting electronic devices and systems using only programming – developing software for most of our capabilities, and even using programmable hardware for the things that software can’t give us.
Of course, there is always room for a few dedicated souls to remain behind – doing highway maintenance instead of building new roads. All the way up our tree of abstraction, we leave talented engineers behind to reinforce the path and even to re-invent it as needed. Sure, we’ve had processors for a long time now, but people are still improving the architectures and grabbing those next few percentage points in performance and capability. Although this becomes a work of diminishing return, it is work that is never truly done. However, the number of engineers we need for this task diminishes over time, and the population of engineers who truly understand the problem tends to age.
It seems that each new layer of abstraction we create spawns a new generation of young engineers who blaze the path. They clear the forests, level the grade, and make the foundation for those who are to come. As these engineers and this technology age and mature, the truly creative work tends to wind down. In a perfect world, perhaps, the length of one’s career would match the longevity of a generation of technology. We could grow old with the engineering music of our youth spinning on our worn out turntables, oblivious to the merits of that racket that today’s kids seem to enjoy.
The pace of technology is a harsh mistress, however. Generations come and go at an increasingly frantic pace. As engineers, we have to either move forward or be left behind. We cannot rest in the relative comfort of re-designing the thing we’ve designed for the past few years. In order to remain relevant, we have to raise our own level of abstraction. Otherwise, we truly engineer ourselves out of a job.
Raising one’s own level of abstraction is an emotionally torturous event. In order to be expert in a complex technology, we immerse ourselves in the details. Our world collapses into a focused beam of tunnel vision – bringing the full energy of our mind to bear on a single problem. It is nearly impossible to ever view that problem as “solved” from that focused state. Our natural inclination is to continue to refine and re-define – in a never-ending quest for a more optimal solution. However, if we want to make the leap to the next level, we have to be able to let go of that problem, take our previous solution as an “IP block” and dive into the details of the next higher level. We almost need to forget the details below and trick our minds into accepting a new kind of currency.
The world today is a chaotic place. When our professional comfort is disturbed, it is easy to find excuses and villains who can enable us to absolve ourselves from our own inertia. If we fail to raise our own level of abstraction, we can pretend our job vanished in a puff of outsourcing or an economic downturn. It’s easier to blame the world than to accept our own failure to move on when the time came. Perhaps one of the biggest engineering challenges of all is realizing that your job is done, your problem is solved, and it’s time to abstract up.
4 thoughts on “Abstracting Out”
Have you experienced a transition in your career where you had to raise your own level of abstraction – where you had do let go of things where you’d invested heavily in becoming an expert, and head off into the unknown land of new, higher-level stuff?
At some point, we need to let go of all that work we spent becoming a Pascal expert, mastering tube amplifiers, or making cool stuff out of TTL parts. How hard is it to up our game?
The report of the death of hardware design is premature. Moore’s Law went into the ICU in 2004. I had a 3.5 GHz Pentium in 2004; We still do not have a 4 GHz Pentium. New chips are smaller and cheaper, but slower and hotter. If you need to go faster, you need more hardware. Full stop.
Multi-core is an urgent, fruitless concept to keep the old game going, where software rules, hardware is an ever cheaper commodity and if it is too slow, just wait 18 months for Moore’s Law to bail you out with faster hardware. Unfortunately, there is no compiler to convert a regular program into an N times faster parallel program. Just because you have 16 cores does not mean you can easily keep them usefully busy.
Answer: Start over with a system design approach that balances hardware and software for best price-performance. That is where new abstractions are needed. FPGAs anyone?
Surely the really clever trick is to re-use knowledge and skills gained in one domain or “abstraction” in new ones? It might also be worth thinking about abstraction not in terms of the building blocks used to create a system: gates, registers, IP blocks; but in terms of what you leave out and what you keep in your model: I/V/t, 0/1 1.2ns, 0x1234/N cycles, (…). On the other hand, with shrinking geometries we have to come up with ever more inventive ways to allow us to abstract away the nasty details like on-chip variation etc.
“Moore’s law describes a long-term trend in the history of computing hardware whereby the number of transistors that can be placed inexpensively on an integrated circuit doubles approximately every two years”
It really doesn’t address CPU speed, or even “can we program a chip with 10G transistors to do anything useful?”