Fog Creek Software
Discussion Board




Leaky Abstractions and Techno-junkies

I think Joel raises some very relevant points in his latest article.

I do, however, take exception to his assertion regarding how many technologies you must know and master to do good work in today's industry. I'm not really arguing with the fact that these technologies are widely used, but rather that they are overused and overhyped and we would do well to change our focus from the technology we use to the quality of the end-product, whatever it might be.

Our industry is absolutely chock-full of technology junkies: the minute a new acronym appears in the trade rags (pushed, usually, by companies that stand to gain by pushing them) almost everybody jumps on the bandwagon. And usually with an incomplete understanding of the technology (e.g. thinking of XML as a programming language).

New technology certainly must be examined and evaluated. So should simpler alternatives! Engineers in other fields have learned to go with reliable solutions over spiffy solutions, usually at great cost of experience.  I think it behooves us to ask:
  1.  What a new technology offers us that we have been able to live without before.
  2.  What is the total cost of ownership.
  3.  Is it an incremental improvement or an actual order of magnitude improvement.
  4.  How much training time will it take to learn the new technology versus extending existing or simpler solutions.
etc.

Jeff Kotula
Tuesday, November 12, 2002

Beside the flawed Hollywood Express example (unlike IP packets, you can't copy an actor and send her twice), I think there is an important point that has not been mentioned:
If a leaky abstraction works well 90% of the time, only 10% of your work force needs to know the underlying layer. 90% of them do not need to learn it. So you can get a away with a large number of cheap/average developers and need only a few people who are better/more expensive. That's why even a leaky abstraction can also reduce the amount of things to learn for the work force as a whole.

Tim Jansen
Tuesday, November 12, 2002

That doesn't make the example "flawed".

pb
Tuesday, November 12, 2002

Except that the abstraction will likely fail equally for everyone, so 90% of your work force is completely unequipped to handle these failures, and may not even recognize it as the type of failure to take to Bob in the next office.  Even worse, if 90% of your workers don't even know about a potential failure, they will not account for it and bugs will creep into your released products.

Your argument strikes me as the old 80/20 rule... since 80% of the people only use 20% of the features, we can get away with only 20% of the features in our product and still get 80% of the customers.  That doesn't follow logically, because each customer uses a different subset.

Mike McNertney
Tuesday, November 12, 2002

Jeff makes a good point.  However, how will the "average" programmers know when they have abstraction leakage?

If they know they need help (i.e., adding two literal strings) they can simply ask thier supervisor or that 1 (out of 10) "super" programmer who does know C++ inside and out.  IN that case, you hire 9 average (read: inexpensive) programmer and then one expert (team leader?) who helps them with the hard part.  Like having an experienced foreman.

HOW DO YOU KNOW WHEN THERE'S LEAKAGE?
Perhaps hiring programmers with average experience (say, just Visual Basic) but with the ability to troubleshoot a problem enough to realize  ".... ahhh... this language is doing something wierd.  Time to call in the expert".

I find a lack of strong troubleshooting skills in hi tech.  Troublshooting skills (problem analysis) allows you to operate beyond your ability because it helps you analyze the uknown.  KNOWING the abstraction/analogy is leaking is half the battle.

Clay Nichols
Tuesday, November 12, 2002

My experience is that working within a 50/50 mix of average and expert programmers works better, otherwise the newbies will take up all of the pros' time.
After all the expert guy needs to understand the problem, show the average programmer how to fix it, get back to his desk and try to remember what he was doing before being interrupted.

Marcos Rubinelli
Tuesday, November 12, 2002

You mean there is time between the interruptions to get back to the desk?!

Attending the wake
Friday, November 15, 2002

*  Recent Topics

*  Fog Creek Home