I’ll bet you’ve had the experience of finding some cool article on a technique you can really use in your work — but then discovering that, once you look at the code, your major reaction is, “huh”?
Source code should not make your scratch your head. It should be self-evident. Granted, some things are complicated in the details, but the overall design should make so much sense that it brings a smile to your face. Unfortunately, many developers are too preoccupied with being “correct” or impressing you with their superior mastery of arcana, than they are with being straightforward.
A lot of us have a huge problem finding the right level of abstraction for each solution. Interfaces with only one implementation or abstract classes with only one inheriting class are usually dead give-aways for over-abstraction. Huge switch case statements, especially if repeated in more than one place, are often a symptom of under-abstraction — but at least they are self-evident. I’ll take under-abstraction in preference to over-abstraction any day, because under-abstraction is a lot easier to fix if necessary.
Jeff Atwood hits the nail on the head again today with this post. Often, he says, the “proper” OOP way of doing things becomes a “productivity tax”. Rather than slavish adherence to OOP theory, he suggests targeting information hiding and encapsulation, simplicity, re-use, maintainability and what he calls “empathy”. That last is just putting yourself in the shoes of the poor sap who has to understand, use, or maintain your code. And you’ll find that quite often, that poor sap will be you, anyway — six months or two years from now when you’ve forgotten the pleasure of the mental masturbation you engaged in when writing the code.
In development, the KISS principle still rocks.
