The Law of Leaky Abstractions and understanding the basics.

Sooner or later, software developers will have to come to the realization that theirs is hardly the only human activity that ends up creating bugs. Sure, other disciplines don't call them by that name, but that doesn't mean they are not haunted by human errors, miscalculations, the passage of time, erosion, bad materials, etc. As a matter of fact, what makes software stand out in this respect is that there is an official (and quite often publicly available) list of all these errors associated to every project. As Joel Spolsky once explained, the complexity underlying our shiny tools is prone to cause leakages:

In an essay titled The Law of Leaky Abstractions, Joel Spolsky wrote, "All non-trivial abstractions, to some degree, are leaky. Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong." For users this means that sometimes your computer behaves in bizarre, perplexing ways, and sometimes you will want to, as Mitch Kapor said in his Software Design Manifesto, throw it out the window. For programmers it means that new tools and ideas that bundle up some bit of low-level computing complexity and package it in a new, easier-to-manipulate abstraction are great, but only until they break. Then all that hidden complexity leaks back into their work. In theory, the handy new top layer allows programmers to forget about the mess below it; in practice, the programmer still needs to understand that mess, because eventually he is going to land in it.

(Rosenberg: pp. 281-282)

We come across this sort of situation fairly often. It wouldn't be the first time my wife runs into a showstopper problem while putting together a set of web pages on iWeb. The applications does wonders as long as you don't stray too far from what it deems the regular path. As soon as you need to do something different or special (or sometimes, even if you don't), you will run into a problem. The GUI will fail to display things just the way you want them. This table or that font just doesn't look the way it should. Yes, WYSIWYG editors are cool. They allow your regular Joe to edit web pages without having a clue as to how HTML truly functions. On the other hand, as soon as something fails you need to take a look at the inside, read the actual code (and, oh, by the way, what awful job these tools do at writing the actual code underlying the whole thing!) and know what you are doing if you truly want to fix it. In other words, you still need to be familiar enough with the underlying technology that you are using. This is precisely the main problem with these tools. They start being developed as a way to provide some help, a way to automate boring mindless functions. Yet, very quickly they turn into these magic tools that will let you do whatever it is you need to do without having a clue as to what you are actually doing or how things truly work beyond all the pretty interface. That's where we run into trouble. It's like relying on speech recognition software without being able to read. As long as the program gets it right, you're OK. But as soon as it has a mistake, you will be totally lost. Actually, it's even worse: even if the program gets it right, there is no way for you to know.