the so SOLID principles

Year after year programmers find themselves faced with a new set of acronyms and principles that dictate the ideal way to develop software. After 10 years in this game it gets rather tedious and tiresome. The problem is you can’t let your guard slip with this stuff, because if you fail to listen, you may fail to find a job.

I have been meaning to write about this since the whole Joel Spolsky vs Uncle Bob debate [1][2]. As it happens, Jeff Atwood beat me to the punch with his article “The Ferengi Programmer“. However, there are a few points I would like to address with regards to the whole acronym waving brigade.

First, let’s look at the SOLID principles. Do most good developers not use a relaxed variant of these things anyway, and have done so for the last 10 years? It seems like we are creating a set of rules for the dumb-ass programmers to follow because they can’t figure out for themselves what is good and what is bad. The problem with this approach is that the average dumb-ass programmer will not even know or attempt to understand the principles anyway. They will just keep typing.

Where does this leave the good programmers? Well they may find themselves trotting along to a job interview and one of the questions they are asked is: “Do you use the SOLID principles when writing code?”.  This person then responds: “What are the SOLID principles?”. Often the interviewer will then disregard the candidate and in doing so may be throwing away the chance to work with a great talent. OK, you may say the interviewer is a dumb-ass for disregarding someone for this reason alone, but then again, I bet you can think of several that would. I’m certain there are people I know who are not aware of the SOLID principles, but who I think are awesome developers.

My problem with all this is that we shouldn’t automatically disregard someone because they can’t state the SOLID principles or that they are not using TDD (oh yes another acroymn), BDD (and another), and DDD (and ANOTHER). God, are there people sitting at their workstation trying to figure out how to squeezing every-single-one of these things into their development cycle. I would bet you quite a bit of money that there is. These folk must get NOTHING done because they are spending so much time trying to do the “right” thing. The consequence of this is that they fail to write code that actually implements ANY functionality. It seems like it is no longer enough to be able to write good software. You also have to know all the latest buzz words. This is sad.

However, despite my reservations, I find myself thinking why shouldn’t we allow “bad” developers to become “good” developers? Is it rather patronising to say otherwise? 

What we all as developers should watch out for is the developer that accepts all these rules blindly, and applies them to EVERY situation. I’m all for writing code the correct way, but we also must be careful how we judge fellow developers.