by Annette
13. June 2007
One of my colleagues runs a thriving therapy practice. She laments that clients come to her with the notion they can be taught say, three simple steps to communication. Or 4 ways to get along better with their child. They want to buy a quick and clearn package of success. She tells me clients resist the fact that it's only when they dive into the personal mess or the personal story that they will see real change in the problem they set out to solve. The abstractions don't bring the healing they hope for.
Apparently the same issue rears it's head in software design. I mentioned the book Dreaming in Code by Scott Rosenberg in my last blog. Rosenberg claime that software packages that bundle lower levels of programming complexity often fail. He sites an essay called The Law of Leaky Abstractions by Joel Spolsky. When developers try to simplify the coding process with these bundles they are not more efficientbut less because they have to dive down and understand all that the packages intended to simplify anyway. The abstractions "leak" because they really don't save time. When problems arise, as they always do in de-bugging, developers still have to take the time to learn the underlying building blocks of the code.
The sustaining truth here is there are no clean fixes to dirty problems. In fact, the clean fixes often means cleaning up the dirt that leaks for a long time coming. Seems it's better to learn how to slog around in mud.
