First, here is where I think each side is wrong:
People that say things like this have just never written a heck of a lot of code.
This sentence, said by Joel, is a personal attack. No wonder Uncle Bob got all heated up. And then he allowed himself to fight back by calling Joel a “business wonk”. Apart from being offensive, this attack went partly amiss: while it is true that one can’t dedicate a lot of effort to running a business and improve their programming skills at the same time, running the business gives an important perspective: Sometimes business considerations are more important than writing clean code. For example, deadlines should be met.
Another mistake on Uncle Bob’s part is the use of the word “principle”. Many commenters on Jeff’s post have pointed out that the principles are not intended to be used all the time, but are more like tools. As tools they are useful, but if this was indeed Uncle Bob’s intent, then he shouldn’t use the word “principle”. “Principle” is defined, e.g., as “a basic truth or law or assumption”. So maybe they should have been called “design patterns”.
In every text that makes several statements, people tend to select the statement or idea they consider the most important. My digest of Joel’s post is this: Don’t overengineer. Don’t blindly use the SOLID or other principles just because they are there.
The real principle is this: Don’t let design get in the way of project requirements or common sense. I’ve learned it from experience after participating in building a set of libraries, which had several problems:
- Interface complexity: The interface was very generic and allowed to do complicated things. Simple things were a special case of complicated ones, so that it was not simpler to do something simple than something complex.
- An inner platform
- Unneeded frameworks
… and more.
I consider this a very important experience and I’m glad I had it right at the start of my career.
I admit I don’t know what “agile programming” or “extreme programming” actually mean, but the project leader was an extreme programming geek, and what I understood is that “extreme” in XP has exactly the same meaning as in “extreme left” and “extreme right”. So maybe the correct term is Extremist Programming.
A good general rule is that most “principles” of programming are useful in some cases, but useless in others. So while knowing them is beneficial, one should beware of dogmatists who will break functionality to fix compiler warnings. (No, that was not a hypothetical example. And if you say “with unit tests, that wouldn’t have happened”, you have a point, but that’s no excuse for breaking functionality.)
In general, as one of the epigraphs in Stroustroup’s book says, “keep things as simple as possible, but not simpler”. For example, if your whole project is 20 lines long, you needn’t even bother to split it into functions. Of course, you should do so as soon as it becomes longer. After all, refactoring is agile, isn’t it? When the code grows to 100 lines long, it will contain several functions, maybe 2 or 3 classes, but most probably no design patterns yet. And so on.
And a final word. While experience certainly does matter, don’t forget that we are not living in a world where old people are the most revered because of their experience. Instead, this is a world of start-ups, where everyone is judged according to their success. And anyone who doesn’t question authority should switch to literate programming.