With some amusement and a good chunk of confusion, I've been following the ongoing debate between Jeff Atwood/Joel Spolsky and Uncle Bob Martin. I won't bother detailing the argument; if anyone reads this blog, they probably are already aware of the salvos launched by each faction (I ran out of words for the last link). My befuddlement stems from the fact that the two sides really aren't that far apart. It seems to me that it would be rash to say that either Atwood or Spolsky completely believes that proposed guidelines like Uncle Bob's SOLID principles are a bad idea. And I'm fairly certain that Uncle Bob has respect for the idea that the Liskov Substitution Principle might be a little hefty for a novice developer to understand in their first years in the market. After listening to Hanselman's podcast with Bob Martin on SOLID, I am convinced that Mr. Martin, though he completely stands by his guidelines, is aware of the complexity that these principles present at first blush. The main similarity between the two arguments is that both Atwood (Spolsky has kind of ducked out of it, and I don't blame him) and Martin are going about laying out rules for developers the wrong way.
Atwood maintains that " Throwing a book of rules at a terrible programmer just creates a
terrible programmer with a bruise on their head where the book bounced
off." And I agree with him. There are, unfortunately, a lot of terrible programmers out there polluting our sacred pool. But, there are even more programmers that don't have time to pay attention to blogs, read "seminal" books on design patterns and programming theory, and prototype all of the hot new ideas as they come out. I've only started getting into NHibernate, even though ORM's have been around for years, and I don't count myself in the ranks of "terrible programmers." To be frank, I just haven't had time to learn about it. And I've found that a lot of programmers are like me, they don't have time either.
I have a colleague that is busier than I am. He doesn't read blogs, doesn't go to trade shows or user groups, doesn't read books, but he's still a good developer. And he wants to learn, it just doesn't always fit into his schedule. As we have worked together, I've come to realize that one of the biggest barriers that he faces consists of the large wall created by acronyms, buzz words, and high-brow conceptual language that make no sense until you have a chunk of time to study them.
Software development is a complex science, without a doubt. But when we create jargon to appease our programming nobility, we not only make it difficult to sell new ideas to the managers and decision-makers in our enterprises (not all of us have the good fortune to run their own company or work for software companies), we also create knowledge obstacles for the programming bourgeoisie. Ninety-eight percent of the development work-force does not have time to keep up with SOLID, TDD, FDD, DDD, ORM, DRY, YAGNI, AJAX, MVC, MVP, Agile, XP, RAD, MEF, Clouds, WPF, WCF, WF, ECM, NAMBLA, POTUS and WTF. My colleague may have been creating class instances dynamically for years without knowing that he's been using the Factory Pattern the whole time. He knows what works, what's fast, and what's scalable and easily maintainable, and frankly, he doesn't give a flying fuck about patterns and practices and principles and acronyms.
As a lead developer, I very much am concerned with patterns and practices. But my main concern at this point is not keeping abreast with the latest theories, its finding out what works for our enterprise and figuring out how to help my peers understand why they should use it. And in this effort, I have found that buzz words and acronyms don't do me a lick of good. What does? Easy-to-use documentation and code samples. That, my friends, is how you sell software developing ideas.
So it was quite amusing to me that Jeff's rebuttal to Uncle Bob was yet another set of acronyms, even if they stand for very simple concepts. A lot of these terms make sense to me because I've taken the time to study them. Terrible developers are staying terrible because the nobility has stopped talking to them. They are too busy talking among themselves in a jargon that few others have the time or inclination to understand. Keep it up, guys. I'll keep trying to edit and translate.