Abstractions

As usual, since I’m commenting something that was written in English I post in English.

I have got a solid respect for Joel Spolsky, he certainly is a professional who knows what a programmer is and how to explain it in clear, strong, words. He is not a paramount for me though and I would go as far as saying that in his posts his chief weapon is rounding up to the biggest whole value (and yes, this is kind of a monty python’s quote).

This often forces me to mentally prune and edit his posts in real time to avoid getting bad feelings while reading stuff that would otherwise have good value to me. So, let me say I dislike his style despite the fact that I reckon he is a great communicator.

One of Joel’s most famous statements is the law of leaky abstractions. It is of course a very controversial statement and its conclusions seem to deny the value of abstraction itself.

I believe neither is true.

It is not a controversial statement as it is just a rephrasing of basic and well-accepted software engineering concepts : an abstraction is a simplification of reality created to more easily address a specific facet of a problem.

It does not deny the value of abstraction either.

Abstractions do have contracts, thus conditions for them to act accordingly to their contracts. A failing abstraction is still an abstraction, it is telling you that the conditions for it to work are not met, which narrows down the issue. A huge value.

I came to think once more about the law of leaky abstraction due to a weird issue with a wi-fi printer I had bought and installed at my parents’ home.

The printer is an HP C4380. Somehow it worked well enough with USB, but when used through wifi it printed only the first 2 lines of the first page. Incidentally, the printer’s own installation software had reported inability to connect to the printer, but I was able, for instance, to query the printer for ink levels, status and other data.

I’ll spare you the details, but after three hours I found out why the print command was failing (which I could state as : “I can obtain a paper-based copy of the document I got on the screen by asking the printer to print it”).

It was because this fancy printer has an MTU of 1466 bytes.

Such genius in the creation of a printer is astonishing, but, nonetheless, by taking a step beyond the basic abstraction, and then more layers, such as WIFI, then TCP, then IP, then Ethernet I finally restored the failing condition : “The sender must use transfer units of equal or smaller size of the receiver”.

Was the abstraction leaky? No, it just required that the underlaying abstractions had their conditions met, which in turn involved more conditions and further layers to have their own conditions met as well.

Returning to Joel’s excellent TCP-IP example: even if mice chew the cable in half my abstraction of TCP will not “leak”, it will return an error, which is perfectly within the definition of the TCP abstraction. The error will be properly abstracted, mind you : just a timeout, not, for instance, a list of packets whose retransmission failed.

This is Joel’s “upper approximation”: he purposefully presents the fact that abstractions have conditions for their validity in a way that makes one believe the whole idea of abstraction is moot. He does not say so, mind you, but so it sounds; the world “leak” is picked on purpose and this is why the law attracted so much attention.

How to manage a failing abstraction? Joel uses the necessity of inner-protocol knowledge to prove that indeed one cannot fully rely on abstractions. But they were never supposed to be fully reliable, if so, they would not abstract away any detail!

This is very clear if one delves in long-lost memories : “If we presume the angle of incidence is small enough, we can apply first-order gaussian formulae to lens-focus calculation”. That’s an abstraction, a model for reality, that simplifies a given aspect of the problem by providing a condition to the application of the abstraction.

It is not very different from saying : “If there exist a live routed path to a given destination (add here a lot of other conditions) TCP will guarantee delivery”

Why do we use abstractions to model reality since they are not almighty and will work only if the conditions are right? We ultimately do so to split concerns among different people. By letting some people take care that the conditions for a given abstraction are supported we can assign some other people to the task of using that abstraction.

These two acts (taking care the conditions are met and using the abstraction) can then be geographically-spaced and time-spaced.

What if the abstraction stops working? Then someone should restore the conditions for it to work, if that someone is your own people then you might be able to fix it sooner than later, which is better, of course.

But this doesn’t mean that you need to have people for recreating all of the required conditions.

As long as you can presume such conditions are maintained by the system in the long term you can define them as “reliable infrastructure”. Which means : “I will spare with learning how to restore the nominal conditions of an abstraction for the sake of devolving more resources to using it”.

You don’t need to have Java programmers who are also Electricians, nor Bakers. But since you are presumed to create your own networking infrastructure, you likely prefer to have programmers who know about what an MTU is.

If you can presume your networking as reliable infrastructure, you can spare with that requirement for your programmers.

One hardly presumes that the abstraction “I can obtain bread by using money” will ever break. But if it does, it is not because “abstractions are leaky”, but because abstractions do have conditions. The reliability of a system is the chance such conditions might fail.

(Later addition, forgot to add it at first)

My parents didn’t presume they would need a trained technician to print a document, since they got one at hand they could have their system meet the required abstraction conditions (changing the MTU of the pc to be smaller than the printer’s), but they could have stayed at their own abstraction layer by following the suggested solution which was included in the manual (error responses) return the printer and pick a new one.

Then again, this is hardly a surprise for anyone. To be forced to accurately ponder which layers to consider as fully reliable and adequate for a given project is a mainstay of technical and general planning.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s