Sunday, January 6, 2008

The power of the abstraction

When talking about technology, I often talk about the importance of abstractions, and it recently came to my attention that many people may not understand what I am talking about.

One of the things that makes our "world of technology" work is the concept of the abstraction. An abstraction is where you take some really complicated thing and represent it in a way that simplifies your interaction with that thing and makes it more easily understandable.

Abstractions are building blocks that, once we build them into our world view, are almost impossible to remove.

This concept applies to software and user interfaces, but it is perhaps more important in computer hardware and software architecture.

For example, think about the history over the last 40 years of the semiconductor. When I was in school, we were all issued something called the TTL Data Book. This book, from Texas Instruments, contained a catalog of all of the basic building block chips available at the time. At that time, these chips might have four "and" gates or "or" gates on it. The chips were *really* simple. To put it in context, one of those chips might have had a few dozen transistors on it. Using a breadboard and a soldering iron or a wire wrap tool, we made prototypes using these really simple chips. There was *a lot* of detail work.

Today, chips have millions of transistors on them and (though I don't know) I doubt anyone is issued a TTL Data Book any more. Instead, what kids get today are tools to work in a language called VHDL. VHDL allows you to design a chip with hundreds of thousands or millions of transistors on it by, in essence, writing software! You then can burn the result of that design onto an FPGA from someone like Altera, which by the way you can test for the most part, without physically building *anything*.

This is an abstraction. And an incredible one at that. All the logic is the same, but the tool has hidden a layer of ugliness, actually several layers of ugliness. We no longer have to think about what happens inside the abstraction. Similarly, compiled languages like Pascal and C were great abstractions on top of assembly language. Java is a great abstraction on top of C, and so on.

What is really interesting when you think about all of this is that if some layer of any of these abstractions were to just go away, it would be *exceedingly* hard to replace it. This is because we begin to forget how to operate without the abstraction. And recreating the underlying building blocks from scratch wouldn't be that much easier than it was to create the first time.

This is why, in software design, the idea of refactoring has become such a useful concept. The opposite of refactoring code is the idea of just rewriting the whole program better. But the truth is that the actual process of writing code captures so many nuances that are hard to reproduce from scratch, even if you have the old code right in front of you. So you really want to avoid rewriting large chunks of code, and instead, to refactor it as you go along, modifying little pieces as you go to make it better.

My point here is that we have come to understand that engineering is not really a process of one big insight or achievement as much as it is lots of very little achievements (grunts) strung together. In an entirely different realm, if we destroyed the entire country's interstate highway system, the fact that we understand how to build roads would not mean that we could quickly replace it. We'd still have to redo all the grunt work. Slowly. No matter what type of engineering you are talking about, redoing it is painful.

And so, abstractions package and hide the grunt work so we can reuse it forever, without ever having to think about that old forsaken layer of ugliness.

And this is a beautiful thing. We just keep building new abstractions on top of the old ones. My current work involves what we hope will be accepted as a powerful and entirely new abstraction for creating web applications. We want to provide a new level of grunt work encapsulation, and to make another leap in the simplification of writing web-based code.

0 comments:

Post a Comment