@Andrew:

That being said, if you can't see the ROI on unit testing, then you are not acting like a professional. The one instance I will conceed is if you own your own company and design your code for interal uses, but if you are working for a in a development capacity, you should be developing good code that is maintainable, that is one of the reasons they pay us the big bucks.

Ah, if the ideal world we all pine for could only exist. Have you ever tried to explain to upper management, a non-technical supervisor, or a client, the value of maintainability? Of testing? Of documentation? Of best practices (whatever you take them to be)? Or even something as basic as clearly writing down requirements before starting development? (Rhetorical question; I've no doubt you've been in those shoes.)

They're always all for it, as long as it doesn't take any more time or cost any more, in the short term. But they never get it beyond that. A developer is generally given a vague set of requirements, which must be met within an arbitrary timeframe and budget. I can't recall how many times I've pleaded with the decision-maker to allocate more resources for testing before deployment. Not once have I ever gotten it.

So, as a professional, I do what I'm being paid to do: get the job done within the constraints given me. That's all the people paying me care about. If I fail at that, then I'm unprofessional in their eyes. They don't give a hoot about whatever principles or philosophy I use to get the job done.

In practice, that often means throwing out a whole lot of things I really want to do, like unit testing. So, should I be professional in the eyes of you or other experts, or in the eyes of whoever is handing out the bucks? I'll take the bucks. If I've done my best to explain what I think to the client, and they ignore it, then I've done all I can to be ethical and professional, other than delivering the expected result. It's their responsibility to factor in all the variables I know nothing about and set deadlines and budget, not mine. Similarly, it's their fault if problems arise later (as they invariably do.)

Of course, I get blamed anyway. As long as they pay me, I don't care. It's part of why they pay me the big bucks (to deliver as expected, AND to be a scapegoat!)

Rules, principles, methodologies, silver bullets, etc. are only relevant to me if they help deliver. That is often the case, sometimes, for some of them. Other times, as in my previous posts concerning inexperienced programmers, that is definitely NOT the case. I wish I could work with guys like you, and the others here touting SOLID, TDD, Agile, etc., who actually understand this stuff already, without requiring years of (time-consuming, expensive) handholding. In practice, I don't (news flash: good developers in short supply).

You do understand, don't you, that you all are the exceptions?

@Ryan:

they are principals not rules. A subtle but important distinction.

I see the point several of you have made about the difference. It's a good point. I'll have to think about that, and on how to use the terms more precisely. Learning something new every day.

OMG! A Pirsig ZATAOMM fanboy posting here, followed shortly thereafter by a Bertrand Russell quoter. You guys just made my day!

Here's another from Russell, then I'm done pontificating on this thread:

The secret of happiness is to face the fact that the world is horrible, horrible, horrible.

I find lists of programming rules very helpful, but I don't actually use them.

So what does that mean? Reading and trying to understand them is helpful because it helps me distill lessons from my actual experience. It helps to crystallize and consolidate concepts I already know, but may know only vaguely and can't articulate.

I also enjoy revisiting some of my favorite rule sources -- Code Complete being a prime example -- from time to time, because the experience acquired since the last reading will always make a few previously overlooked principles jump out and shout.

But actively using them ... that's foolish, I think. No set of rules can capture the infinite landscape of constraints and trade-offs in every real project. Navigating that landscape takes experience, flexibility, and some ability, not mindless adherence to some mantra. And those mantras are absolutely useless to novices; rules and methodologies are incomprehensibly abstract without actual experience to ground them.

@Just wow:

Could someone who actually agrees with this forum post, please give a non-trivial example of how not adhering to any of the SOLID principles leads to a better design?

Yes: when a challenging project with specific requirements needs to be completed on deadline by a team of limited experience. In other words, the real world.

There's nothing wrong with the SOLID principles; they make sense to me. But I've been programming since the days of card readers and teletypes. They WON'T make sense to those with little experience. They don't know when or how to apply them appropriately. They get bogged down in the attempt.

So trying to follow them changes the focus from result to process. And that's deadly.

It's the job of the lead programmer or manager to see that good principles are followed, perhaps by guiding others invisibly, without explicitly mandating or even mentioning those principles.

@Just wow:

So the design that is produced by inexperienced people working to a tight deadline is better than that of one done to SOLID principles?

A design produced by inexperienced people trying to adhere to SOLID principles won't get done on deadline, or at all. If it does ostensibly get done, it'll be a pile of crap.

The point is, trying to fit a project into the rules, when the people don't have the experience to know how to use the rules, distracts from their actual responsibility: getting the job done.

Again, it's up to those who are more experienced and in charge, to manage things according to whatever principles apply, based on their experienced judgement. At that level, the rules are wise and productive.

It's like the dichotomy between a coach and a team. Good coaches have much deeper understanding of the sport than their players. But they DON'T try to jam that knowledge into the players and force them to follow it. That overloads the players, getting them so distracted and confused that they play worse. Instead, the good coach applies his experience on a play-by-play basis, with specific instructions to the players -- not general rules.

@Andrew

Let's face it, it's not like learning the individual principles of SOLID is difficult, they're easy simple guidelines. Let's take your real world example for a second, if a manager spent a grand total of 5 minutes with his/her team of limited experience programmers he/she could easily teach them one of the principles, say Dependency Injection, how is that a hard?

I completely disagree there. They are NOT easy, they are VERY abstract. You and I understand them because of lots of experience. Most of them won't make a dime's worth of sense to novices. And yes, they are hard to teach. 5 minutes? More like 5 years!

Why do I say this? Been there, done that. I started programming in the early 70's. Still do it frequently. Still learning new stuff every day. But have spent as much time in the last 20 years or so managing others, starting businesses that require developers, and occasionally teaching. The issue of how to get real work done with inexperienced hires is not a theoretical exercise to me -- it's a continuing challenge that affects me personally, including how many dollars are in my pocket!

But the qualifying word in this argument is inexperienced. Those who understand the principles on first reading already understood them BEFORE reading them, at least intuitively -- and that's due to experience.

So, it's ironic: the rules, formulated by the experienced to help the inexperienced, are really only understandable by those who don't explicitly need them!

I'm disagreeing with the idea that these rule lists, sets of principles, methodologies, etc. are appropriate to feed to novices, not with the rules themselves.

Later you wrote:

An IT manager's job is very similar. If a programmer has limited experience, you teach them how to code the right way. It might not help you on a current project that is already a big ball of mud, but it will help on future projects. That is what teaching (or coaching) is all about.

I completely agree with that. The important thing is to have that manager, coach -- somebody who know the ropes -- there to do the guiding and teaching, rather than expecting newbies to figure it out on their own by mandating a bunch of generalized, abstract rules.

@Andrew:

Coaching on a play-by-play basis is just micormanagement to the nth degree, and in any sort of long run will fail. If a ball is hit to deep right field, my right fielder needs to know where the cut off man is going to be standing and the cut off man needs to know that with a man on second, he's going to have to get that ball to home ASAP to have a chance to get that runner at the plate. Coaching this on the fly will result in failure 99% of the time, having your players know what to do at least gives you a chance for success.

By the way, I agree with you there and understand the point. I think what you've done there is flesh out my skeletal analogy with more nuance. In other words, you overturned my generalized rule with a specific, real-world counterexample! Which is another reason to not slavishly follow rules -- they're too brittle and lacking in nuance to apply all the time, but others here have made that point well already.