Jeff Atwood Finally Jumps the Shark

Posted by Kevin Pang on 2/11/2009 | Comment

Well, we all knew it had to happen eventually. After years of great blog posts and insightful commentary on the programming world, Jeff Atwood has finally jumped the shark in his latest post which essentially says "programming is hard, let's go shopping!".

Now I'm not entirely sure why Jeff and Joel have decided to wage war against SOLID. At first I thought it was just a bit of verbal diarrhea and I sympathized. I am very aware of how easy it is to say something stupid when you're just casually bantering with a friend or colleague. However, from the tone of his post and the subsequent comments it received, it seems that lines are being drawn and the battle is on.

Honestly, I don't really understand what all the commotion is about. SOLID isn't all that controversial in my opinion. Jeff's main problem seems to be that by introducing so many best principles and practices, we run the risk of overwhelming programmers with too much guidance:

The bigger and more grandiose the set of rules you come up with, the more severe the danger. A few broad guidelines on a paint can begets thirty rules for painting, which begets a hundred detailed principles of painting..

Pretty soon you'll find yourself believing that every possible situation in software development can be prescribed, if only you could come up with a sufficiently detailed set of rules! And, of course, a critical mass of programmers patient enough to read Volumes I - XV of said rules. You'll also want to set up a few messageboards for these programmers to argue endlessly amongst themselves about the meaning and interpretation of the rules.

He has a point, of course. If we reached the point where programmers relied so heavily on rules that it hindered their ability to code, then yes, we would have a serious problem on our hands. The problem is that this scenario is so laughably far from the reality of what average programmers are like that I wonder if Jeff and Joel are secretly just messing with us to see how much commotion they can stir up.

Dance puppets, dance!

The reality of the situation is this: the average programmer has probably never even heard of SOLID and couldn't care less about it even after it was explained to them. The idea that we are soon going to be swamped in bureaucratic rules that force us to think too much about the software we write is ludicrous when sites like TheDailyWTF still exist. If anything, we should be in support of anything that will force programmers to think more about the code they write, not less.

In the end though, Jeff has a hundred thousand RSS followers and I have orders of magnitude less. His post appeals to the lowest common denominator. It reinforces the belief that quality of code doesn't matter and it will garner massive support while mine will be lucky to get 20 people to even read through the first paragraph. That alone should be a testament to how skewed the software industry is in terms of those who care about quality code vs those who don't. Given that, are we absolutely sure we want to go down this path?

Enjoyed this post? Share it with others!

Comments

What I got from Atwood's post was a warning about the dangers of over-processizing ... of making slavish adherence to a set of rules (that started s guidelines, and there is a difference). As someone who's lived through attempted implementations of both LBMS and RUP, I've seen the results of that first-hand.

The statement:
"Pretty soon you'll find yourself believing that every possible situation in software development can be prescribed, if only you could come up with a sufficiently detailed set of rules!"
Is right on the money -- in many cases, what started out as a short list of guidelines quickly becomes a culture that cries: "Oh, my god! Something we didn't consider has occured, let's form a committee and develop a procedure!"

@Paul

I agree that Jeff has a point. Too much bureaucracy and procedures are a bad thing. SOLID just doesn't seem to fit that mold though. It has nothing to do with processes and procedures. I can't even imagine how a company would go about instituting a policy of, let's say, only allowing SOLID code.

I wonder if Jeff and Joel are secretly just messing with us to see how much commotion they can stir up.

Wouldn't that just be the status quo?
-m

I think at some point as an "A-lister" you have to keep the conversation up. I feel like Jeff swings between some great points I wish everyone would read (like the "Don't go dark post") and link bait.

This seems to be a bit link baitish. Let's be contentious and call out something, but vaguely give a rationalization we can fall back on later to defend our position by expanding on in a reasonable way.

If anyone has doubts as to what the Coding Horror article meant, read the comments. No matter what Jeff may or may not have intended to write, his article was taken as "programming is hard; let's go shopping!" So before the counter-counter arguments start, I would ask that everyone skim the blog comments to see how his article was actually interpreted.

For the lazy, direct link:
www.codinghorror.com/.../001225.html#comments

Why are we decrying the possible, potential, future implications of following SOLID principles when right now hardly anyone involved with software development follows any principles, or follows the principles of "Inheritance over Composition" and "Maximization of Stored Procedure Usage"

Frankly, if abuse and rigidity of following SOLID principles was a problem, I think we will have finally arrived as an industry/profession.

When did SOLID become a term? I feel so behind the times.

I only follow the KISS and DRY principles.

As for SOLID, I feel much of it applies to frameworks; yes, we want our java and .net to adhere to it, since we can't patch them to suit our needs. But for normal apps (read "ones I work on"), do we really need to follow all eleven points?

Good post!

Ha ha ha, so true. If only too many rules being followed was a problem in our industry! What a wonderful problem we would have. "Oh no, this software just follows too many good design practices! There is no creativity!"

"that force us to think too much about the software we write"
I've never seen a rule that says that. In fact, it seems rules are used to NOT think about the software, and instead simply think about following rules. Seriously, just actually thinking and using your intuition without consulting rules often works better, and it depends ont he size and scope of the code.

I sometimes wonder what it would be like if I could stop playing catch-up for six months and just write code the way I've learned how to. The techs I use are generally obsolete by the time I've finished reading the book about them...maybe Jeff has a point and that at some point you just have to cut some code with the rules you know *today*

In general .NET is a few years behind Java in mentality (not features mind you) and also .NET generally comes with sharper cross-cutting knifes lowering the incentive for abstractions/layers.

So perhaps this explains why SOLID does not sound so appealing Jeff, i.e. DI and AOP is still not something you stumble upon often in the .NET realm?!

I don't know about the rest of you, but I'm constantly desperately searching for ways to improve my code. More importantly, I want to work on the fun stuff! I don't want to fix bugs or try to read cryptic inter-weaved code.

Never bash SOLID or any other attempts and providing some structure and guidance. It's something I crave.

How do I keep up? I listen to development podcasts while driving, I listen to others, and possibly most importantly, I write.

I'm just glad to see that there has been a backlash to those comments and that atleast some of us really do feel that quality matters in software and that the SOLID principles really go hand in hand for creating quality software.

@Chad, seeing 'the principles of "Inheritance over Composition" and "Maximization of Stored Procedure Usage"' really depresses me since this entirely sums up every business system I've worked on.

Here is the problem. If you have been programming more than 10 or 15 years, you have seen multiple methodologies, principles, frameworks come and go in that time. I have a tendancy to tune out people who are preaching the next gospel when I am still busy assimilating the last gospel. What is worse is that some of the most visible proponents of the newest methodologies and principle don't have a clue as to how to motivate people and instead resort to bashing those who refuse to follow them. Definitely not Dale Carnegie trained.

We spend way too much time worrying about what others in our industry are or are not doing. If it is a good idea/principle, then it will be around for a few years and will begin to gain in popularity/usage.

I believe what you're seeing is a trend toward the future of computing and programming. If all you've every worked with is OO then you strive to follow principles to make things better. The problem is that there is no OO algebra. There is no way to reason about OO programs. This is vastly different from something like the relational model or functional programming. Both of which have an algebra. If you'd like to expand your horizons and start to see the future you can look here:

www.stanford.edu/class/cs242/readings/backus.pdf

Good post!

The thing that has occurred to me over the last couple of years is that methodologies, principles and practices that emerge are not simply people saying "Look what I invented", but ideas and techniques gradually and naturally forming themselves after being tested and proofed. "We know this works well in a range of projects, so why not write it down and give it a cool TWA (or actually FWA in terms of SOLID)".

I love reading up on design patterns and methodologies, not to follow them word by word, but they have all given me alot in terms of further expanding my programmingskills and the perspective I have on large-scale projects. I've been in too many "screw-that-let's-take-this-shortcut" projects, and seen where they have ended up when changes or updates needs to be done. There is a place for everything, and rules should be applied where they are appropriate. Not every project can be structured in a way to meet the repository-pattern or by using dependency injection throughout, but I'm guessing the patterns could be applied in some parts of the application.

Anyway.. Maybe I should start my own blog instead of writing long comments

Also! Check out Rob Conerys response to Jeff. I think it is pretty spot on:

blog.wekeroad.com/.../

It is true! I've never even heard of SOLID and couldn't care less about it even after it was explained to me.

Slight tangent, but has anyone actually brought in an "Agile Expert" into their shop and try teach their devs about Agile?

I was looking at some of the courses and they are great. 3 day course for doing: charts, 10 step lists, guidelines, principles...LOL.  There is a reason why agile is called "common sense" development and everyone does it different.  Same concept applies here.

Do you want to write code or look pretty doing it?  Does your company want to make money or have nice code?

Coming from 3 small companies I work(ed) for, you learn very quickly that all these principles are great except there are things like deadlines and clients don't give a crap whether you wrote the best framework that can stand the test of time for 5 years.

I agree with the blog post...most developers don't even know what SOLID and even less are applying it.

I think the flavor of the post was that blindly following the rules gets you nowhere fast. If you understand the principles and know the REASONS that you might break the rules in specific cases, then I think you're ahead of the game.

@Yngve Nilsen

Thanks for linking to the Rob Conery post. Very well put and a solid analogy. Although the commenter who compared it to chess had an even better one.

Either way, I agree with some of the commenters that Jeff's intent may not have been to dismiss patterns and practices. Again, I see his point. The problem is how it comes across. The comments in response to his post are actually more upsetting than the post itself.

It's interesting, I didn't read any of that into his original posting. And it didn't really seem that the comments provided much insight into anything aside from people expressing their personal beliefs and interpretations of said posting.

I happen to think that the idea of SOLID is, well, solid. And I think that they could be good rules to follow. Though I think that largely they are inherently followed by experienced programmers to an appropriate degree without feeling too much pressure to make sure every last character written conforms.

I have however seen many programmers who believe that their skillset is much higher than it actually is. Typically these are the people who can approach zealot status in their following of rules - even for cases where they don't completely make sense.

I guess from that standpoint I can understand what he was trying to say with the original post - at least it's what I took away from it personally.

There were two comments that stood out to me:
First was the quoting of Eric Raymonds "Rules for Unix Programming", where one states "Rule of Diversity: Distrust all claims for 'one true way'." and the other was :

Good programmers know the rules, and when to break them, and, therefore, say "I need no damn rules!".
Crappy programmers see the good programmers saying that and just repeat them, skipping the first 2 steps.

@Kevin Pang

Yeah, I loved the the chess analogy. I'm actually not sure how to interpret what Jeff is trying to communicate. To me it might actually look like he's trying to communicate exactly what we are now discussing, but he's doing it a little more discreetly than many of the comments

Either way, I sort of get where he's going with it, but I think the analogies of Rob Conery and his commenters surpasses the arguments of both Jeffs post and his comments. Honestly admitting I take shorcuts myself, and do things quickly because "they have to be done quickly", I really WANT to follow the rules, and I spend alot of time reading up on patterns and methods in order to make that the way I program intuitivly. I think this will evidently elevate my codequality to great heights without necessarily spending more time coding it. As a consequence of quality, the scalability and durability of my projects will most likely be alot better.

I remember learning how to play jazz on the piano 10-12 years ago. Back then I was told to read the rules, learn the rules, remember the rules. Upon doing this, I should throw the rules out the window and play from my heart. The rules would then be the basis of my intuitive technique... I think the same applies here.

In the end though, Jeff has a hundred thousand RSS followers and I have orders of magnitude less.

Perhaps, but you have much cooler followers, ergo you're cooler than him...

Also, your posts have stirred mild hubbubs before ;> but have never "jumped the shark".

I love that barbie account on reddit

> "programming is hard, let's go shopping!".

Awesome.

Pingback from blog.schauderhaft.de

Programming should be Taught just as a Craft by Schauderhaftes

You nailed it Kevin, we're being played. The aspects of the conversation that should matter, don't. It's interesting that Steve McConnell is JA's "coding hero," but now little of that matters.

rp