I'll tell you one thing, the Gang of Four book is probably one of my most disappointing programming reads of all time. Completely useless to me. Strange that I can have a successful programming career without understanding that book...

Oh and Scott Ambler blows too.

Yes, strict adherence to the rules is like filling your garage with a huge number of shiny power-tools. Then, for every project you do, you feel obligated to make use of all of the tools you have, in order to justify them. That's work for a few huge projects, but how do you use a nail gun when hanging curtains? Sweeping up leaves?

Extreme behavior begets extreme results. :-)

Paul.

I completely agree with this post. You summed up my thoughts exactly. Strict software development methodologies are an attempt to guarantee good software using (good|bad|random) programmers.

For me, the most valuable thing a methodology offers is a common vocabulary for a team to use, so that it's easier to communicate as you solve programming problems. Beyond that, it's just one of a million different ways that code could be designed and written.

The only true indicator of success is the quality of your people. Hire really smart coders and don't constrain them any more than necessary.

I see these object oriented rules as guidelines for my design. Obviously there are some that will be followed (I'd be stupid not to) and others that won't be followed.

There's nothing objectionable about his principles, you say? I can't be bothered to find out, mainly because there's something very objectionable about presenting anything as big lists of individual PDF files.

Interesting time for a post like this, because it comes at a relevant time as I am learning the adapter design pattern, which constitutes my first real foray into these things. Anyways, my thoughts on the matter are that for rules and principles, it's my opinion that you should follow them strictly at first, and then modify them as need be. They serve as a good starting point, but inevitably, in trying to apply them, you will modify or discard some or all. Eventually, you'll gain enough experience to know when a rule is applicable.

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.

While you don't explicitly say that what you're saying is meant to be in opposition to what Bob Martin is saying, it's implied. If you intended that, then you've probably never seen Bob speak or read his writing aside from those principles. Yes, he advocates remembering these principles and taking them into account, but that's a small part of what he advocates. The primary thing he advocates, by far, is taking responsibility for your choices and working in a professional manner. That's exactly what he's all about. The SOLID principles, etc., are just a way to help remember how to do that (in the context of object-oriented design), but I think Bob would have nothing but contempt for the idea that they could replace independent thought.

(Help! The two developers who've inspired me more than anyone -- Bob Martin and Joel Spolsky -- are fighting! What am I to do?)

While I agree with Jeff's overall points in regards to methodology, I don't think OO design principles constitute a methodology. Like the instructions on the paint can, the OO principles are applicable and correct most of the time. The trick is having the experience to know when they do not apply, and that is often just a question of granularity (don't sweat the small stuff) and cost (don't build a Ferrari where a Chevy will do).

I don't think it's helpful to set everything up as a false dichotomy -- "You either follow these principles to the letter, or ignore them!" That's just not the way the world works, but I guess it makes for more exciting blogs and podcasts. :-P

I have to get a chuckle when I hear "we follow the <foo> principle of software design".

IMHO, software engineering isn't "wash, rinse repeat."

It's funny to me that until I finished I pictured the Ferengi Programmer as the *good* thing to be. I was thinking that he would be an example of having rules and concepts that are generally helpful ideas but feeling free to ignore or tweak them if your experience and knowledge says it's for the best.

This post perfectly illustrates the danger (yes Jeff, you *are* the most dangerous blogger on the Internets ;)) of blogging. That is, the SOLID principles are constructed in such a way to minimize many common pitfalls of software development. They help to form a guideline for building robust, easily extensible, and maintainable code that are all but proven to work toward these ends. However, as is usually the case, a blogger can come along, dispense some anecdotal perspective, and effectively nullify everything that makes SOLID, well, solid.

-m

aargh.

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.

Oh boy did I agree with the comments you and Joel made. One of you used the word "bureaucracy," and I thought that perfectly expressed the misguidedness of SOLID. Bureaucracy is not inherently bad. I actually like a certain amount of administrative fussiness. Bureaucracy becomes bad when its starts inflating itself for its own sake and becomes an exercise in micromanagement, the illusion of control, and (if you'll pardon the expression) a bunch of mental masturbation.

I keep thinking of things to write about this, and coming back to one thing. Aargh.

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?

A VERY good article!!, thank you for your insight. I really feel a sense of relief.

regards

When ENIAC was designed John von Numan used serial architecture for the bus.

Before the machine's bus was constructed he came up with the parallel architecture.

He realized that the machine would be far faster and cost less to construct if they switched the design from serial to parallel.

So, Johnny boy went to the Army with the proposal (ENIAC was built during war time under Army control).

The two star sitting there picked up the original (serial) spec book and showed it to von Numan stating that 'we are building this thing to spec'.

Bottom line: ENIAC was finished in time to make a significant impact on the war (atom bomb calculations among others) but if they had listened to von Numan it would have been finished sooner, at lower cost and ran faster.

So much for the rules...

In all fairness to the Army it was war time and they were greatly worried about Nazi Germany's progress on atomic weapons. Even though (unkown to them) the German scientist were so afraid of Hitler that they would not dare propose building an atomic device because the lead time was multi-year and Hitler had a very nasty habit of having people shot for being late on a project...

So what does this have to do with rules?
Too strict an eforcement of rules results in:
a. Low or no creativity
b. In extreme cases (such as the German scientists) no attempt at creativity what so ever (can you blame them?).

Good thing for us...
In that instance strict rule enforcement saved the world!

@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.

Programming is bringing fluctuations to the discret all-or-nothing world of computation.

"That is, the SOLID principles are constructed in such a way to minimize many common pitfalls of software development."

This reminds me of something Paul Graham wrote:

"One of the differences between big companies and startups is that big companies tend to have developed procedures to protect themselves against mistakes. A startup walks like a toddler, bashing into things and falling over all the time. A big company is more deliberate.

The gradual accumulation of checks in an organization is a kind of learning, based on disasters that have happened to it or others like it. . . . It's natural for organizations to learn from mistakes. The problem is, people who propose new checks almost never consider that the check itself has a cost."
http://paulgraham.com/artistsship.html

The principles of SOLID or any big "M" Methodology are intended to prevent people from making mistakes. The problem arises because the cost of preventing these mistakes often exceeds the cost of the mistakes themselves. Unfortunately, corporations seem to love this sort of penny wise, pound foolish thinking.

Reminds me a lot of Eric S. Raymond's *excellent* rules for Unix programming (except Eric's aren't teh suck). I'm not a Unix guy at all, but I keep them posted on the wall of my cube. I like how there are 17 of them, too. He didn't feel the need to make up 3 more just to have an even twenty. Anyway, here they are:

1. Rule of Modularity: Write simple parts connected by clean interfaces.

2. Rule of Clarity: Clarity is better than cleverness.

3. Rule of Composition: Design programs to be connected to other programs.

4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

5. Rule of Simplicity: Design for simplicity; add complexity only where you must.

6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.

7. Rule of Transparency: Design for visibility to make inspection and debugging easier.

8. Rule of Robustness: Robustness is the child of transparency and simplicity.

9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.

10. Rule of Least Surprise: In interface design, always do the least surprising thing.

11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.

12. Rule of Repair: When you must fail, fail noisily and as soon as possible.

13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.

14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.

15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

16. Rule of Diversity: Distrust all claims for “one true way”.

17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

"Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they're never a substute for thinking critically about your work."

I've always seen these things as tools for thinking critically about your work. They are all a little too abstract to try to apply directly without any real thought, anyway.

They also provide a common vocabulary for discussing code, so you can say things like "this class doesn't follow the single responsibility principle very well" and other people will (hopefully) understand what that means.

@ Jef R.

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

oh wait..

"The principles of SOLID or any big "M" Methodology are intended to prevent people from making mistakes."

Really? Have you read them?

Seems to me that SOLID is all about fostering agility in large OO code-bases (not excluding small of course). Agility is coding is something that Paul Graham has preached over and over.

-m

So what you're saying, Jeff, is the opposite of what Martin suggests; don't use any rules v. use rules. So then your rule is to have no rules. In the end, you're both suggesting following a "rule", they're just different rules.

So what's the argument about again???

Maybe what he's saying is; I only have one rule for you, and this is the only rule you should follow...

Don't follow any other rules.

:p

How would it be different if SOLID wasn't about rules, but about principles? Oh, wait, it is.

How would it be if there were demonstrably good principles that, by our understanding and awareness of when and how to apply them, made it possible for us to write software that worked better, got released faster, failed less frequently, cost less and made our customers happier?

I'm just askin'

I've only been writing software for 30 years or so*, and my understanding of SOLID doesn't get much past SOL (and I'm still a bit shakey on "L") but what I do understand of it definitely helps me deliver satisfied users better than before. And isn't that really a large part of what it's all about?

(* I'm not bitter, you understand, just old and a little tired.)

Brute Force Development - <a href="http://softwareindustrialization.com/BruteForceDevelopmentBFD.aspx">http://softwareindustrialization.com/BruteForceDevelopmentBFD.aspx</a>

"Uncle Bob" had some valid points, but then he turned to outright insults and lost all credibility.

@Just wow

It doesn't. The point is that sometimes such rules are excessive and unnecessary. It would literally take *years* to refactor my current projects to fit these principles. The projects are working and don't have any issues. The company I work for would gain absolutely nothing, aside from maybe one problem down the road may take slightly less time to debug. This would be a terrible return on investment.

That's the point.

Jeff you make a good argument by backing it with the Dreyfus model but these rules that Uncle Bob advocates are really targeted at beginners and advanced beginners to practice so we can have a bare minimum of software quality. So I believe the SOLID principles are perfectly valid for being introduced to all members of these groups. As they progress to competent and expert levels it is ok for them to make more decisions about what works and what doesn't from the SOLID principles as long as they don't make negative progress. It would at the very least reduce the submissions to TheDailyWTF if everyone had a grip of these basic software design principles.

I think this post can be summed up as:

"I am surrounded by coding ninjas, therefore, I do not need to follow SOLID principles because my guys rock."

The funny thing is that if you looked at the code, the ninjas are probably following many of the SOLID principles anyway.

-m

@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.

"It would literally take *years* to refactor my current projects to fit these principles. The projects are working and don't have any issues. The company I work for would gain absolutely nothing, aside from maybe one problem down the road may take slightly less time to debug. This would be a terrible return on investment."

As long as you stay with that company forever, then you are probably correct. You've got the system figured out, so why would you ever want to refactor to the SOLID principles? And then if you leave that company, who cares anyway?

-m

@Jeff R.

In response to Just Wow's question:

"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?"

You responded with:

"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."

Sorry, your answer just doesn't make any sense. You've not shown that ignoring SOLID has produced a better design, just that in the "real world" often projects are designed ad hoc. What have you proven?

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?

Maybe you aren't aware that the majority of time spent on a project is maintenance, including something as simple and trivial as Dependency Injection goes a long way in maintaining the testability of existing code.

Should every application follow every single "rule" of programming? No, of course not, especially if you are building a small application of limited use. But saying "be your own unique snowflake, don't follow the rules" has resulted in more bad code than good code, I can guarentee you that.

"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."

You keep saying this. Presumably we are minimally talking about recent C.S. grads. What makes you think that they would not be able to understand SOLID principles? Nothing in them that I have read requires 30 years of experience to wrap my head around.
-m

This is utter nonsense. The best programmers from the '50s and '60s had little of this.

Maybe start blogging more and advertising for you and Joel less...

Programming is not manufacturing.

It requires a thinking brain and, often, breaking the rules to arrive at a solution.

Solid principles are ingrained in quality work.

Enforcing solid principles onto programming process is like enforcing plot rules on a poorly written novel.

I guess that's why they're principles and not laws. It's up to you the developer to decide, which of those principles may need to be sacrificed dependent upon what the objectives and more importantly the constraints of the project are.

If you set out to adhere to as many as possible then prioritise those, which are most useful to your business / problem domain.

Most importantly, once you've decided, which SOLID principles to follow, remain consistent.

SOLID principles are just a collective of sound OO advice collated by an articulate, talented and busy engineer over his career. I for one am glad he took the effort to write down his and other peoples observations and to come up with a mnemonic for us to remember them by.

I look forward to his guest appearance on your podcast Jeff.

@Fogus

"Really? Have you read them?"

I have read them.

@Fogus
"Seems to me that SOLID is all about fostering agility in large OO code-bases (not excluding small of course). Agility is coding is something that Paul Graham has preached over and over."

Paul Graham doesn't think much of OOP in general. "I think there are five reasons people like object-oriented programming, and three and a half of them are bad" http://www.paulgraham.com/noop.html

@Jeff R.

"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."

A good coach is constantly teaching his players and doing whatever he can do get the best performance possible out of them, so I'm really not sure where you are going with this analogy.

Let's put it this way, when I coached baseball years ago, if I noticed that a batter was dipping his back shoulder or was pulling off the ball, I'd teach him not to, and more importantly, I'd explain to him why it is bad. That is part of my job as a coach, to help him become a better player so next time he's up, he won't make the same mistakes.

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.

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.

"Paul Graham doesn't think much of OOP in general."

Oh in that case, SOLID sucks.

-m

@Jeff R
"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."
You have it backwards. If you study the Dreyfus model:
<a href="http://pragmaticstudio.com/dreyfus">http://pragmaticstudio.com/dreyfus</a>
that Jeff used to justify his post then you would know that beginners or those with "little experience" need a recipe and rules to follow so they can start their journey to becoming experts. In short, it actually makes perfect sense to introduce the SOLID principle design rules to beginners and this is also backed up by numerous studies. It's important to also note that the rules are meaningless unless they are also accompanied by a goal.

Oops entered the comment without entering "orange" and the blog software clobbered the link when it tried to translate it to HTML.
http://pragmaticstudio.com/dreyfus

@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.

Right, software is not like manufacturing. It has more in common with building architecture, which has a set of principles that architects use in *most* cases.

I think this is the mistake that Jeff is making, confusing Principles and Rules. If as a discipline we can't say we have Principles that guide how we do our craft then how do we even talk about what it means to be a "good developer." How do you judge a good developer? Just because some geek can hack a linked list doesn't mean anything. But Principles aren't rules. Principles are guding lights. Rules are rigid do's and don'ts. If you go against a Principle, there is a high liklihood you are wrong, but there are cases.... If you go against a rule, if it really is a rule, you are always wrong.

The SOLID principles have been discovered over many years of collective developer experience. It makes no difference to me that the best programmers of the 50's and 60's didn't have these principles. I don't use punch cards. I use C# or java, or python. Would a building architect ever speak of architectural design principles as "bureaucratic"? Would you hire one that did? He might be able to satisfy you once, but how reliable will that architect be ignoring all the principles of his craft?

But, they are principles, and when I have good reason to, I go against them. I don't need good reason to go with them, but I do need good reason to violate them.

The problem I have with Agile is that they try and sell the idea that there exists some single set of universal principles that can codify the construction of software. They try and sell their principles as some sort of "Newtonian Gravity" for software development. The insinuation is that if you don't adopt these principles, your project is going to fail.

The problem is that there are a huge number of counter examples.

For example, Linux is a successful project where nobody is in the same room together, where there are no scrum masters, where there is no unit testing and where pair programming is almost never done. Yet, it's successful.

In fact, it's laughably easy to find successful projects that are almost "anti-xp." Where there so far away from being Agile that they're in a whole different universe.

I'm not sure what these people are trying to prove.

"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."

Exactly. Beginners should focus on things like which data structures to use when, basic algorithmic ideas, and how to use revision control and development tools effectively.

How many applications are going to require a pure interface anyway? Seriously, it seems like every Java developer goes through a stage where everything is an interface. Until they realize that's not necessary 99% of the time.

These are good "best practices" to know and understand. But I don't think they are beginner concepts in the slightest.

@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.

My opinion on this topic is:

"Rules are good only if they tell people what *NOT* to do and also explain *WHY NOT*. They are bad if they try to tell people *WHAT* to do or *HOW* to do it."

If rules tell me what I must do (or how I must do it), they take away my freedom more than anything else. They pretend I'm a stupid moron, incapable of making my own decisions. They force me to do something or do it in a certain way, even though every fiber of my body may tell me it's wrong, just plain wrong.

On the other hand, rules that tell me not to do something may sometimes be necessary. Laws work like that most of the time. Or at least they should work like that. Most laws don't tell you what to do (though these exist as well), but they make up a very long list of things you must not do. Of course this limits your freedom as well, but if a rule says "Don't do it that way ...", it still leaves me the freedom to go for any other way I want, as long as its not that way. This is much more freedom than saying "Do it exactly that way ...", which leaves me no freedom at all.

And finally, a rule without a justification is just harassment. If I ask somebody "Why shouldn't I do that?" and the reply is "Don't ask stupid questions, just don't do it, okay?". Then this is no reply and the rule is bullshit in my eyes. I can understand why there is speed limit on streets that are in the middle of a residential subdivision or pass a school or kindergarten. It makes sense to put a speed limit there for all kind of reasons. A road that goes somewhere through the middle of nowhere, is absolutely straight, you can see 2 miles in every direction, it has hardly any traffic, no woods, no animals, but it has a very restrictive speed limit -> bullshit. There is no justification for it. Leave it up to the driver to judge the situation: Taking into account his driver skills, the condition of his car, the weather, etc. he should be able to make a reasonable decision on how fast one can go and if goes to fast and dies in an accident that could have been avoided at lower speed, well, things like this happen. You can't put the whole world into cotton to prevent that anybody will ever die again because he made a mistake. People make mistakes and some are fatal.

Mistakes in software development are rarely fatal, so it is okay to allow people to make mistakes. Just set up rules if you can justify them, if you can explain why somebody should not do something when getting asked. If this justification is *sound*, the person will understand it and won't have an issue following that rule.

@Jeff,

"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!"

Come on now, you're just being silly at this point. 5 years to understand one principle of SOLID?

There are some horrible developers out there, and since the IT industry pays so well, I'm sure that will never stop. So I will freely admit that there are people out there who are practically unteachable. But how often do you give important new development to those people? Almost never.

A lot of development these days is maitaning and enchancing existing applications. If an application was designed "right" in the first place, it's actually very easy for any developer to follow the existing structure. They don't even need to know why they are passing in IDataStore in the constructor of a class, just that it's the "way it's done". Doing it differently would actually be more difficult, so they could churn out good code all day long and not even know it, throw in a code review here and there, and they might even learn something.

@jeff
"I think this is the mistake that Jeff is making, confusing Principles and Rules."

I don't think that Jeff is the one making this mistake. An awful lot people, especially novice coders and clueless managers, latch onto the rules of some Methodology and treat them as holy writ, even if the Methodology calls them guidelines or principles. This is the problem with Methodologies. People with little experience tend treat them as hard and fast rules, while people with enough experience to treat them as guidelines are usually experienced enough to do the right thing without having to consult the Methodology.

Never forget that They're Just Rules:

http://www.xprogramming.com/Practices/justrule.htm

http://c2.com/cgi/wiki?TheyreJustRules

The irony being... "rule" questions make up a huge portion of the stackoverflow site.

My beef with "rules" or "best practices" is, is that some people may read about a best practice, (a square), and then fit that best practice into their task at hand (a circle).

Young Mr Atwood,

You say:

"When Ron says there is an "absolute minimum of practice" that must be in for an agile project to succeed, I want to reply that I believe there is an absolute minimum of practice needed to have a competent opinion about things that are needed -- and that in his post he does not achieve that minimum."

Ron Jeffries is hugely more experienced than you at this stuff:
http://en.wikipedia.org/wiki/Ron_Jeffries

I've conversed (on a mailing list) with the man, and he really does know his onions.

On the other hand, there are a few people who come out of the woodwork every time some sort of software engineering topic is mentioned. In particular, things like the SOLID principles and design patterns and so on get them all hot and bothered.

If anybody doesn't think those things are worthwhile, then what they're really saying is that it is possible to write good code without understanding what good code is. Be a bit of a fluke if they did, IMO.

I used to wonder how people could possibly object to this stuff (although I've seen enough poor code to know that not many people take any notice of it).

Then I read about the Dreyfuss model, and that seemed to be a possible explanation. Have a read of chapter 2 of "Pragmatic Thinking and Learning", then read Jeff's blog and the comments, and see what you think. I reckon the "second-hand incompetence" stamp could be used fairly freely :-)

It's kind of worrying thinking about your self image, too, after that chapter.

To those who have a problem, I would say that these things really do only seem prescriptive up to a certain level of skill. Beyond that point, they become more internalised and intuitive. Eventually you may move beyond them and become a thought leader yourself (although don't expect many of us - myself included - will ever be that).

Personally, for some years I've used questions about these topics to sort out who to employ. I don't care if someone can write a regex off the top of their head. I do care whether they can write, or have the potential to write, good code*. To me, that means they have to have thought about how to do that.

*Actually, now that I think about it, being able to write a regex off the top of your head might be a strong contraindication :-)

Odd to hear Bob Martin's SOLID railed against as if it were a Methodology (big-M). I have been around for a while, and there were originally over 11 important principles (and no methodology, by the way). Here is a promotion of the five most design-oriented principles, and explanations of how they work.. and so this is a Big-M Methodology with a lot of subrules and strictures and creativity-killing, brain-numbing requirements?

Mind you, there is an agile methodology, but it basically boils down to "test your stuff as you write it", "have short iterations", "work together", and "keep track". It even includes 'retrospectives', whose entire purpose is to let the team choose how it is going to work together. I lived through SDLCs and RUPs and Structured and you-name-it. Agile is the anti-methodology.

This whole series of strawman-bashing posts here is too silly to swallow.

@asdf,

I feel the exact opposite to be honest. Knowing what structure to use, how to connect to a database, the difference between an Abstract Class and an Interface, etc. (you know, the basic interview questions people as developers) are all available on google.

Give me an inexperienced young developer right out of college who understands how to build an application over an "experienced" developer who is responsible for developing horrible, unmaintainable applications any time.

Your mother is a Ferengi!

@Jeff R.

Sorry, it's not my fault you gave a horrible analogy. ;)

I regard OO rules as a dictionary of terms for explaining what I'm doing.

@Jim Cooper
The text you quoted isn't by Jeff Atwood, it's from a blog entry by James Bach (http://www.satisfice.com/blog/archives/174) that Jeff is quoting.

Better design is better design.

If in your real life your real boss tells you to make it fast and ugly, or you have any other reason to sell better design for something else - do it. That does not make better design worse.

If you do not understand how to make better design, it does not make it worse. If you can not get benefit from better design - it does not make it worse.

For me those principles are just to know them and do what I think is appropriate. Very often I think following them is a good idea. Following them blindly is like following any rule blindly.

Actually SOLID is not that hard. It does not take much time to extract interface for client. It does not take much effort to depend on abstraction, etc. And it gives you fine grained control over your code, which I think is very agile.

If you know someone who reads the book and immediately follows everything in it without any doubt - I hope that's a girl :) I know few good principles for her.

I've never thought about any book as something that limits my freedom to develop software how I think it should be developed. And for junior who thinks that everything in his program needs to be in one static method of one class - those principles are a good start to try thinking in different way. That's what books are for, to let you think in different way.

Jeff .... for the principles involved (Bob Martin, You/Joel), how about this .... have the programming community come up with a project (nothing too involved, but enough to exhibit one's programming methodology) and you guys code it (Jeff and Joel can work together since they see eye-to-eye on this). Display the finished projects on the web so that everyone can look at the code and make their own judgements about which one is better (more readable/maintainable/extensible/etc.) - even let us vote on it and show the results publicly. I think this would be better (and more educational for all involved) than these endless theoretical tiffs.

Jeff,

This is not about rules. It's about principles. Quoting doesn't imply understanding.

Software design principles are like having a really good sports instructor when learning and perfecting a sport. They are there to help you be the best you can and give guidance on how to improve. Can you go ice skate or wrestle without a sports trainer. Sure, but will you be as good at your craft without one, probably not. Just like you anyone can create software. But, that doesn’t make them good software developers. To be good you have practice and seek the advice of leaders of the craft (design and principles). To scoff the advice because you think it is a pain in the rear is similar to not listening to your sports instructor because the work is too hard. But, once you master those teachings they become second nature and you don’t have to keep all these rules in your head all the time and you step up your ability at your craft.

Good principles in software are like the basic rules in most religions (basically, "Be nice to others, don't steal and don't kill"). It seems to be in human nature to take such a rule and end up with the spanish inquisition. Or in our case, take things like "DRY" and end up with SCRUM.;)

While I agree with the general idea "these rules are good, but don't be fundamentalist about them", I don't see how the Single Responsibility Principle can ever be useful. It seems to be another name for the Functional Decomposition Anti-pattern ( http://sourcemaking.com/antipatterns/functional-decomposition ).

IMO, there are two reasons why you might not read the instructions on a paint can:

One, you are a child who doesn't know any better, and you go and make a mess.

Two, you are an artist who could have written the instructions youself, and you know exactly what you are doing making up your own rules.

There are a very tiny talented minory who are born into the second category, but the rest of us need to humbly do our time following the instructions until we really understand what they mean. Anything else just holds our profession back. I think it's a shame you can't seem to see that, Jeff.

I never follow the rules on the paint can. I just dump the toxic contents down the drain and to hell with the consequences... let the people downstream deal with it.

Is that what we're saying?

"there's a limit to what you can fit on a paint can"
If developing SW were as easy as painting there would be no problem to find good developers, nes pa ? I think you oversimplify things here, Jeff.

"As brief as the instructions on a paint can are, they do represent the upper limit of what most people will realistically read, comprehend, and derive immediate benefit from."
And you think that SW devs fall in "most people", that are not concerned with details and have difficulties with comprehending hard stuff ? C'mon.

"Expanding from a few guidelines on a paint can into a detailed painting manual is far riskier"
You think that those painters that must paint interiors of tankers that carries special chemicals (just example) just read what's on paint can ? There are home pet projects, demos and enterprise apps worth millions of $. You think that dev skills levels for all these are the same - just instructions on a paint can ?

"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"
Why you give SW dev so little credit ? The majority of us IMO know how to be (self)critical, we tried a lot of different approaches and have failed enough times that we know that sometimes the answer is "it depends". There is no silver bullet. And in design you always have to make decisions on sometimes contradictory parameters.
SW is too complicated that "every possible situation in software development can be prescribed". But that doesn't mean that engineering principles are worthless.

Worse yet is the idea that software engineering is monolithic. That the same set of practices should be used for developing every type of software. This is patently absurd. Software is enormously diverse, perhaps more diverse than any other engineering discipline. The most reasonable practices for engineering a cowbell app. for the iPhone are dramatically different from those for engineering youtube which are in turn dramatically different from those for engineering the software that runs the Mars rovers.

With so many rules soon we will have programmers and programming paradigm lawyers.

Principles aren't rules nor methodology nor practices nor laws cast in stone nor bureaucracy. SOLID is anything but Ferengi Programming.

Rarely have I seen foundational teachings been twisted and misinterpreted that much as in this conversation. Bureaucracy, (bloated) rulesets, and (too many) guidelines can be made out of any sound and sensible practice. They aren't build in from the beginning.

For crying out loud, look the word up in a wordbook: Principle comes from latin principium meaning beginning, origin, basis, fundamentals. In this context they are obvious generalizations of years of observations, distilled experience as somebody else named it. They provide a basis (not THE basis) for reasoning or a guide for conduct or procedure. A principle is not an absolute rule. A principle is a proposition stating a fact or a generalization, accepted as true and basic.

One of the basic reasons to use principles is exactly about that less is more, to avoid drowning in rules, bureaucracy, and the "Ferengi mindset", because you can let yourself be guided by one principle rather than 10 rules and 117 exceptions.

Whether you like or not, everything you do is guided by some principle (good or not), otherwise your actions would be chaotic, frantic, or just plain messy. Focusing on principles rather than paradigms, features, bloated guides, is economy of rules. Once you expand your understanding of the principles, you can get around all those rules and their numerous exceptions.

Each of the SOLID principles is a proposition based on experience. You cannot dismiss experience thus easily, especially not experience from 40 years of work, including work with other experienced people. The Liskov Substitution Principle is even based on science. Do you have to accept them as truth? Of course not, but to do so without any critical thinking would be ignorant and mindless.

No matter you previous experience, you can learn from them, derive from them, and build on them. It is a matter of thinking.

The OO principles as laid out by Robert C. Martin in his online articles were my entry to thinking about design, not just design, and I've learnt ever since, while thinking critically about these principles, so they sure bear a lot more weight now than when I first recognised them. No bending of truth here, just expansion of context, and more experience, and better intuition for why, what, when, and how to derive from them - or not, exactly because they are principles, and nothing else.

Jeff Atwood, you are way off here, and this is mounting to distastefulness, the very least. This is less than a cheap shot.

"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."

I would want to educate my engineers on the principles that are effective and applicable to their work. They are more likely to achieve quality, maintainable software if they are exposed to what that might look like!

"They don't even need to know why they are passing in IDataStore in the constructor of a class, just that it's the "way it's done"."

Until it breaks. Or the data store being implemented works differently from how IDataStore thinks a data store should work. Then you are dooooomed to spend days figuring out the class hierarchy.

"Give me an inexperienced young developer right out of college who understands how to build an application over an "experienced" developer who is responsible for developing horrible, unmaintainable applications any time."

SOLID and unmaintainable are not mutually exclusive.

Kent Beck has also responded to some of Joel's comments regarding unit testing and TDD:

http://www.threeriversinstitute.org/blog/?p=29

I couldn't agree more! Thanks for the great post.
It is so nice to see people to start coming and saying it is okay not to use the xxx best practice! I am so sick and tired of being told that I am not a "professional" simply because I don't write tests! I verify the system myself and I don't see the ROI on automating them very high at all. I do think that some of the design patterns are useful, but most of them seem to be geared towards make believe contrived examples. In the real world classes are usually 1000+ lines of code and so this myth of small objects is really quite funny to me.

Anyways, thanks for representing, what I think is the majority of programmers. These OO and TDD zealots are the loud minority IMO and are too full of themselves.

"I don't see how the Single Responsibility Principle can ever be useful. It seems to be another name for the Functional Decomposition Anti-pattern ( http://sourcemaking.com/antipatterns/functional-decomposition )."

Having only one reason to change (SRP), is not the same as having only one reason to exist (Functional Decomposition Anti-Pattern).

Another way to approach understanding SRP, is to explore Cohesion ( http://en.wikipedia.org/wiki/Cohesion_(computer_science) )

I think some of us are looking at this backwards. To paraphrase: I don't design and code while mindlessly following the rules, but if the final product doesn't conform to several of the rules, I know it is a bad solution.

@Dennis Decker Jensen
Jeff Atwood, you are way off here, ...

And I agree.

A good post.

Unfortunately rules are something that PHB's and organisations thrive on. From their point of view when you leave it up to discretion, you leave yourself open to uncertainty and risk. Rules are a way of mitigating uncertainty and risk. Rules keep the Morts in line.

I totally agree with what you say though. It's better to view all advice as guidelines, and not strict rules. Sometimes you will favour some over the other, but programming has such a diverse area of application (ie pretty much anything) that it's impossible to create the one ruleset to cover everything. Back when programming only cared about matrix multiplications in Fortran life was easier.

It's why we all ask 'What is the best way to do x?'. There are a few lazy people out there, but for the most part we just want to make sure we're doing things the right way. We all want to maximize output while minimizing effort.

I think it's been said a number of ways in the responses, but I suspect that folks aren't recognizing that the 'rules' in question, are not rules, but are instead 'principles'.

In plain techno-speak: rules != principles

The Ferengi Rules of Acquisition are not functionally equivalent to Object Oriented Design Principles.

Principles help guide and inform and are imprecise, rules are proscriptive and precise,

asdf,

"Until it breaks. Or the data store being implemented works differently from how IDataStore thinks a data store should work. Then you are dooooomed to spend days figuring out the class hierarchy."

What?

First off, interfaces don't "think", they just outline a contract. So if my IDataStore interface has a "void InsertCustomer(Customer customer)" the XXXDataStore that implements it just needs the method. IDataStore doesn't tell it how to do it's job. So that point is invalid.

Secondly, how is passing in an object (IDataStore) into a class' constructor more difficult to comprehend (by a massive magnitude apparently) than instanciating an object (XXXDataStore) in the class itself? You can't possibly think that.

At the risk of repeating myself (agile joke), under what circumstances can a developer create a better design by not following SOLID principles?

Desmond,

I don't do TDD (never liked it) or like Agile Development (personally, I think it's overrated and more buzzword than substance), so I'm not a zealot.

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 company 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.

No matter what changes you make to existing software, you can't be 100% confident that your changes won't break something. But adding unit testing to your work helps you approach that 100% mark a lot better than "I verify the system myself", which as an aside, is a close second to "It works on my machine!" in the developer lame excuse hall of fame.

A great example of this is at my previous position where we had literally dozens of applications that all remoted to a Window Service that contained the companies business logic. A change was made to an existing method (ignoring the Open/Closed Principle) that the developer though was only being used by a company website. He changed the website as well, it went passed through QA with no problems and was pushed to production. Two days later we noticed problems with something completely unrelated, it turns out that a long forgotten applications (built in Fox Pro) which used Web Service which in turn remoted to our Business Logic was no longer working.

It took days to resolve the problem and we almost received a fine from the FCC. Now, should an overworked QA department have caught this problem? Maybe, I mean, if they have to check 30 applications every time anything is changed the company couldn't function. But proper unit tests would have caught this problem within minutes of making the change.

The moral to the store is being proactive as opposed to reactive is generally the most cost effective.

You wrote:

"Expanding from a few guidelines on a paint can into a detailed painting manual is far riskier. The bigger and more grandiose the set of rules you come up with, the more severe the danger."

It puzzles me that eleven articles on how complexity can be reduced (mainly by controlling dependencies) is bad, while you choose to use a programming language that needs a 408 pages book to describe something basic as “generics”: http://tinyurl.com/dzmh4a

It is generally accepted that dividing a project into modules eases the development process. The SOLID principles simply explain how to do this in practice. If you work on a reasonable sized projec, you simply need to take care of dependencies between modules. Or you can ignore the issue and hope for the best… If you choose not to ignore the problem, the SOLID principles is a good starting point.

I wrote a comment on the podcast here: http://tinyurl.com/atvjtu
You and Joel misunderstood the intent behind "The Single Responsibility Principle". The principles are not so rigid as you understand them to be.

Gewwwwgle.

@Andrew
"A change was made to an existing method (ignoring the Open/Closed Principle) that the developer though was only being used by a company website. He changed the website as well, it went passed through QA with no problems and was pushed to production. Two days later we noticed problems with something completely unrelated, it turns out that a long forgotten applications (built in Fox Pro) which used Web Service which in turn remoted to our Business Logic was no longer working."

Now I think this is just the sort of situation where Jeff and Joel said that people should use unit testing. Their examples in the podcast were the .net framework and an encryption library, but a business component that many different programs depend on fits in the same category.

So many words with so little said.

Chris,

I was just commenting on Desmond's post in particular. He took Jeff's "don't always follow the rules" to mean "unit testing isn't necessary" which nobody else was saying.

The nice thing about all of the programming "rules" is that there almost always one that fits what you really want to do. Of course following that rule may break several others!

The way I see it the analogy of having a garage full of tools, just allows me to pick the tool I want. If I have just a few tools, well you can pound in a screw with a hammer, but a screwdriver works better, and a screw gun works even better then a screw driver.

You do have to learn to recognize which problems are screws and which are nails.

I think We stretched this analogy about as far as it will go.

Jeff,

I am wondering how you jumped from principles to rules. Rules are usually only good for beggining developers, or anything really. Principles are deeper. When you run into a situation in which you have no prior experience what do you use? Guess work seems a little hackish too me. I always fall back on "first principles". Without principles how is one to improve and further the practice? Experience and talent only get you so far. Without principles one can not stand on the shoulders of giants (Parnas reference).

Also, don't become an Amish Programmer.

@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?

"You want to know how to paint a perfect painting? It's easy. Make yourself perfect and then just paint naturally." -- Robert Pirsig, Zen and the Art of Motorcycle Maintenance

I can't help thinking that a lot of this business about design rules is just misguided -- you need to have a "feel" for design, and I don't think it can be taught. Some people have it, some don't. The ones that do can get better at it by practice, but for the most part I doubt that the people who are really good at this stuff have spent much time memorizing rules.

Do you think that Jonathan Ive (designer of the iPod: http://en.wikipedia.org/wiki/Jonathan_Ive) has books full of rules in his office that he consults all the time? Somehow I doubt it.

@Jeff R et al

Please don't confuse the principal with the implementation of the principal. The SOLID principals are sound...the difficulty in making them happen is your own creation.

SINGLE RESPONSIBILITY - DON'T MAKE A BIG BALL OF MUD.
OPEN CLOSED - DON'T MAKE A THING THAT CAN BE INADVERTANTLY TROUNCED BY ANOTHER THING.
LISKOV SUBSTITUTION - WHEN POSSIBLE MAKE THINGS MODULARLY SO YOU CAN CHANGE LESS LATER.
INTERFACE SEGRATION - DON'T MAKE A CLIENT DEPEND ON INTERFACES THEY DON'T NEED.
DEPENDENCY INVERSION - DON'T MAKE SOMETHING CONCRETELY DEPENDENT ON SOMETHING ELSE, RELY ON ABSTRACTIONS

Those make sense...which pattern you chose, how you actually get it done are language issues and shouldn't be confused with the difficulty of understanding the principal..which I disagree with you, they can be taught in minutes...the how might take longer if they don't know the common pattern solutions, but that's a seperate issue.

And again...like has been said...they are principals not rules. A subtle but important distinction.

For my money SOLID principals fall into the same camp as "Write the code as though the guy who is maintaining it is an axe murderer who knows where you live."
http://www.codinghorror.com/blog/archives/001137.html
http://www.codinghorror.com/blog/archives/000610.html

I'm currently working on an ASP.NET MVC based product (read: site) and after hearing/reading many of blog posts about this rule, that rule, this idiom. I thought that for a new project I'll try to follow them. After about 3 weeks of coding I feel like I had gotten nowhere and everything was just so over-complicated. Then it hit me...

I'm experienced, I've been programming since my Commodore 64 and QBASIC. I don't need a set of rules to help me make sure my product is flexible, reliable and easily maintainable. I can do that with my own judgment and insight.

I completely agree with what you said Jeff. I just hope others finally realize like I did that these rules really only hold back the experienced programmers.

@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.

"Ferengi" in Hindi means "white guy".

Rules/Principles are not in themselves bad. Used wisely, they make life easier.

People who form a naive and concrete fixation on the "one true way" based on parroting but not really understanding said rules - often forming a circle and parotting the rules together around a great big whiteboard - that's bad.

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell

I agree with you about the importance of not become in a "Farengi"

But thsi quote is a really bad moment

"Quality Doesn't Matter That Much"

You cannot say in any proffesional context and not to expect to be hardly criticized

@chad

The irony is that you are probably using this principals, but by another name. The goal of them is to get to that flexibility you mentioned. If you know the principal as another thing in another shape and form...good on ya.

I think it's a common trap for beginner and experienced a like to try to take a 'new' concept and apply it too liberally and rigidly.

This is such a strawman.

Programming is complicated. There are different levels of complexity though. The simple contact form that takes a few fields and saves them to a database and/or email is on the low end. It doesn't need any of the above principles. Enterprise applications with complex business rules and multiple integration points are on the other.

OOP, DDD, SOLID and other design patterns and techniques are principles that gear towards the more complex. Yes there will be dogmatic programmers that learn the singleton pattern and try to use it for everything. That's no reason to disparage the learning or use of patterns. I agree that critical thinking is still required, but Joel again has missed the point. These principles are something that help developers write better code for more complex solutions. Once they are absorbed, the developer no longer has to adhere to them as a dogmatic set of rules. They become part of him.

This goes hand in hand with Joel's statement "quality doesn't matter." As others have already mentioned, that's just plain irresponsible. I think thats because joel either doesn't do much real programming anymore, or he just hacks crap together. Quality does matter. I'm stuck maintaining a very low quality application that could use a few of those patterns and principles, and the lack of quality costs the client money, money, money.

How do you write higher quality code? By learning principles and practices that other, more experienced developers discovered before you. Same as any other industry.

Bureaucratic programming. Please. The majority of developers do not suffer from too much design patterns, or too much SOLID, or agile, or waterfall for that matter. They suffer from whipping out cowboy code in a pure chaos environment, using simplistic drag & drop, data driven, vb-like techniques.

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."

Maybe the issue with those that try to follow these rules dogmatically and use them everywhere is that they are trying to tackle it all at once. Start with one. See if and where that helps you. Then add another. And another. Soon you'll find the way you program has slowly changed for the better.

I can't decide on this debate. Is there some publicly available code representing the two sides we could judge against each other? Maybe even Jeff/Joel code versus Uncle Bob code?

I like Andy Hunt's view of the subject: the people who need the most context-free rules are the absolute beginners (this is from "Pragmatic Thinking and Learning: Refactor your Wetware")

I would be more willing to take this article seriously if Jeff and Joel could show some evidence that they actually know what these principles are. Sorry, but linking to them is not sufficient evidence.

@Jeff R.
"In practice, that often means throwing out a whole lot of things I really want to do, like unit testing."

I know it sounds counter-intuitive, but you will find that you are *more* productive writing unit tests than not. You need to get the hang of it first (it takes about a week, IME), and to pick your time. You shouldn't bother with the UI (there are better tools for testing that), although you can test UI logic if you package it up right. You won't be able to test report layouts very easily either, and you shouldn't test 3rd party code (assume that database, 3rd party library, etc works).

When you next have to write something with a bit of logic, give it a try. You don't have to tell managers and clients everything ;-)

@Desmond
It's nice to see satire in action :-)

Are we forgetting the most important rule. KISS. If we keep complexity at its lower limits, our code will be both easier to maintain and run more efficient. I have seen OO designs that would have worked better as procedural code. There are other times where OO reduces complexity. There is spaghetti code out there that works wonders(just don't try to reuse). Whatever it take to Keep It Simple Stupid.

It's a great idea but, there are always self important fools who think that they "have to do something to help out the future generations" when the best thing to do in most cases, is nothing at all.

Although geared more towards politics, this argument fits. Jefferson said it best: " the government that governs best, governs the least ".

Too bad there are self important fools in EVERY field of practice.

I went crosseyed trying to read that list.

Interesting, V, that:

"Ferengi" in Hindi means "white guy".

Also, in Ethiopian Amharic, "Ferenge" means "foreigner" but colloquially, "white guy."

*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.

If anything, we should be *encouraging* developers to think more about their code and abide by some sort of best practices.

Man, you are misleading a lot of young software developers who read your blogs for advice. You can't be so irresponsible.

This blog should be condensed to this. The rest was blah, blah, blah. Your getting better talking about useless crap though.

"Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they're never a substitute for thinking critically about your work."

I get what you're saying here, but I don't think it's coming across quite right. "Rules", "patterns", etc, are still excellent things to learn and practice. Certainly don't follow them because you're supposed to, but because they make sense to.

A programmer might have 90% of the thought in their head and knowing about some of these proven techniques may complete that other 10% of the puzzle. Understanding techniques can save you a poop-ton of work before you code yourself in to a deep hole.

The point I *think* you're trying to make is to use your head. Make good decisions. Make educated decisions. Do what's right for the given situation.

Sheer ignorance.

What makes someone articulate on things like use this pattern, or follow this guideline? Some have pure thoughts, others have hidden agendas, but it all comes down to passion for their work. So having said that, let’s just let everyone express themselves and be grateful we have access to all these readings. Problem is when software houses enforce these "insights" as rules upon developers. It’s the failure to understand, yes that OOP is nice stuff, but can it give me that 100% CPU performance I’m looking for? Or maybe, you’re not concerned about performance but things like versioning and code reusability. Perhaps, both! Costs, schedules, discipline also get involved to make matters worse. But one must realise there are so many possibilities (a.k.a. real-world scenarios) that it would be naive to put them under a single faith.
On the other hand, the... rely-on-the-team-of-super-experienced-programmers-only is so disconcerting. There has to be another way, and there is... become a plumber!

No wonder the Java and Ruby communities think we're idiots!

Cowboyism strikes again. Have fun leading your little horde of outlaws, Jeff.

"I value the skills, experience, and judgment of my team far more than any static set of rules"

Seems shocking to me, that Jeff and Joel continue to absolve themselves while *still* clearly illustrating that they *don't understand* anything about SOLID. Not even that they are simply "guiding principles".

SOLID principles are not "a static set of rules". Jeff's continued ignorance in the face of learning is annoying and damaging to the community.

Please have the basic discipline to actually learn what you are arguing against before you describe it falsely and then shoot it down. Please also check out what is a 'Straw Man' debate tactic - it's clearly your favorite device.

But slavishly following the "no rules" mantra is also a path to failure.

Jeff, I generally like and agree with what you say. On this, unit tests, and TDD you and Joel are completely off base.

SOLID is not laws. SOLID is a set of guidelines that you should be mostly following anyways, even if you don't subscribe to the latest fads in the agile community.

TDD is not about quality, that is just a pleasant side effect. TDD is about creating loosely coupled architectures, and prooving your assumptions before going off and writing massive amounts of code.

It is really easy to build straw men with this stuff, and I am not going to do that (although Joel did when he went off on TDD not that long ago). However I think you genuinely don't understand what you are talking about

Hmmmm, perhaps the comments themselves are more interesting than their content?

That so many people can make reasonable arguments on either side, implies that the target of those arguments is subjective.

Engineering, if it is nothing else, is a quantitative, objective approach to consistently building something. Art is subjective, science is not.

That leaves these comments as a testament to knowing how 'little' we know about actually consistently building software. Any group of professionals that is this highly polarized over basic issues barely belongs to anything that could (or should) be called a profession.

Paul.

@Jeff - well said.

I have seen many implementations of "Agile" development, or other various SDLC implementations that work wonderfully for one or two people for one or two projects. Unfortunatly it is the case that most people who develop and pick the methodologies don't have to practice them. This decision, like most technical decisions, should be, upto, or at least made in collaboration with the developers.

Otherwise it would be like telling a construction engineer what materials he/she is allowed to build a building out of. Okay - not exactly... but anyway...

Personally I'd be had up for murder if I were put into a paired programming environment, yet other people here work better in pairs.

Your guilty of exactly what you're accusing Bob Martin of. Making claims without any real-life experience, you have clearly had no experience applying these principles in any real life situation (you even said so yourself) yet you seem to be sure that they're bad. Not only that but you seem to have made it your personal mission to tell everyone about it. This is quite irresponsible as you have quite a lot of influence in the community, people think you know what you're talking about.

The SOLID principles are just that, principles, not rules. They point to what to strive for. They don't tell you what to do in every situation. Applying these principles allows you to evolve your design. They point you in the right direction instead of telling you exactly what to do. In applying these principles (yes I DO have experience applying then in practice) I have found they're the opposite of what you claim them to be. These principles allow me to work without doing very much "big design up front". Without much rules. They allow me to develop my intuition when programming making me a better craftsman.

I'm sure you can develop working, even great software without using these principles. We've all seen you do that. Please tell us about your experiences doing that. But don't bash something you have no experience working with just because you don't like the sound of them, that's unprofessional.

> If anything, we should be *encouraging* developers to think more about their code and abide by some sort of best practices.

The types of developers who could benefit from SOLID a) aren't thoughtful enough about their work to care and b) won't read much of anything.

http://www.codinghorror.com/blog/archives/001004.html
http://www.codinghorror.com/blog/archives/000635.html

This is why I'm a fan of the simpler "instructions on the paint can" method.

> Man, you are misleading a lot of young software developers who read your blogs for advice.

If we treat young developers like they can't think for themselves, then they won't!

> But slavishly following the "no rules" mantra is also a path to failure.

Is it even possible to write software with no rules? There's always *rules* : Will my code compile? Will customers pay for this? Does working on this make me want to gouge my eyes out? Does what we're building even make sense?

> This decision, like most technical decisions, should be up to, or at least made in collaboration with, the developers.

Absolutely.

Well I'am very much thoughtful about my work to and I try to read as much as I can about SW development.
I'm developing SW for almost a decade and a half.

And I think that I still can benefit from SOLID principles.

@craig,

"Bureaucratic programming. Please. The majority of developers do not suffer from too much design patterns, or too much SOLID, or agile, or waterfall for that matter. They suffer from whipping out cowboy code in a pure chaos environment, using simplistic drag & drop, data driven, vb-like techniques."

Some large organizations -- I would venture to say the kind Kent Beck et al. typically consult to -- are knee-deep in waterfall. Others -- a dot-com startup rushing to market, for example -- may suffer from the cowboy syndrome. Whether these are bad things in their respective contexts and whether they are widespread has nothing to do with whether SOLID is a good thing, as much as you'd like to make that implication.

Jeff, how do you think we as developers improve ?

It seems that what are you saying is "read few instructions and go code", and learn on your mistakes.
I agree that we all learn by doing and learn on our mistakes and get more experienced.

But, how this negates that we use what others have discovered before us ?

Please, if you do not agree on SOLID give us concrete arguments. Saying just "it's bureaucratic" and "sw is not developed this way" is just not enough.

I find it odd that the SOLID list contains both the Liskov Substitution Principle and the Dependency Inversion Principle. The former is a hard and fast rule about how inheritance works in C++ (and most similar languages, as far as I know), and should not be violated without much thought and care. The latter is a nice way of solving a certain type of problem, but absolutely should NOT be used as a default solution -- making your code more complex to add flexibility you may never need is just daft. Premature abstraction is as big a problem as premature optimization.

I think software engineering/development, whatever you want to call it is a lot like martial arts.

Jeet Kune Do was massively misunderstood.. Its a fighting _method_ - not a system that has belts/levels etc. It is about training, understanding your body studying different arts and taking *what works for you* and applying it. Sure, there are the basics (how to throw a punch without smashing your hand, basic blocks etc) but once you have that, you should "go with the flow".. Some people may be better at Western boxing, Muay Thai, Tae Kwon Do etc.. Take from those arts what works for you and train in that.

Software should be the same.. We should all learn the basics (syntax, "Hello World" etc.) and then go from there and see what works for us.

SOLID not for you? Fine. Agile not for you? Fine. Should you publicly bash something without ever REALLY working with it? Never.

I've seen many flash Tae Kwon Do guys talk like that and get knocked out in < 10 seconds by a Muay Thai practitioner.. Equally I have seen cocky Muay Thai guys taken to the floor and literally broken by Jui Jitsu guys..

What should they have done? Studied the other art for a bit, found its weaknesses and exploit them, find its strengths and harness them.

Take from things what you will, apply them and do what you do well. But don't knock something you do not truly understand or have not "walked it's path".

I think wrapping the principles into a single acronym may just be an excellent way of getting people to go "what is that?" - giving them the interest to study something else and what they can take from it.

what? there's stuff on a paint can besides the colour? who knew...

I agree 100% following general guidelines is good, following rules avoiding to take design decisions ("as this can be inferred from rule X") just bad.

Guidelines, particularly in the absence of experts and mentors, are useful.

It's just a shame that so much education is still focused on the rules rather than to explore the landscape to evaluate the most important guideline to consider.

@Wookie: '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.'

If I could up vote this I would!!!

Programming is still a craft. and all the rules are rules of thumb. Design patterns, anti-patterns, Go4 etc. etc. Are all rules of thumb and ideas from other craftspeople.

If it could be systematised like a factory making cars it would have been, but programming is actually designing the factory and its systems not making the cars. It isn't a factory kind of enterprise and may never be.

I think I read this either here or the Pragmatic Programmer years ago and I always have to resist jumping on my soapbox and saying - rules are no substitute for thinking. Design patterns are no substitute for actually understanding what you're doing...

So these guidelines are useful, but they are guidelines. You need to know why before what or how. Most people just jump into their comfort zone and start throwing code over the wire.

This is true of every creative endeavor whatever: music, painting, playing Go. The experts say "there are no rules" because they have internalised them. This confuses the newbies who, after an oldtimer tellse them this, then gets told "you're doing it wrong".

Never let an expert tutor a newbie. Newbies should be tutored by people who still remember what being a newbie was all about, and what it's often about is memorizing and applying rules whose point you only really understand later.

They are called principles, not rules, and they should be treated as principles, not rules.

@Jeff
>> Man, you are misleading a lot of young software developers who read your blogs for advice.

>If we treat young developers like they can't think for themselves, then they won't!

That is not true. The solid principles will help young developers to think about writing better code. How many of us have not seen complex classes with several thousand lines of codes from novice developers, classes with dependencies to other enormous classes. The SOLID principles in combination with agile thinking will contribute to a better code.

By reading all of these comments, it certainly appears that philosophy is a favourite hobby of developers. No wonder there are so many blogs around! And I don't mean that in such a bad way, there's a lot of usefull knowledge and experience being shared to the public. The only problem is some of the articles get people excited as if they were reading the works of the Mesia or the Antichrist - replace these with other fictional characters if you like!

If someone is trying to use some past experiences (theirs or their peers) into works of art/philosophy/science and draw conclusions based on them, then maybe they should get themselves familiar to the logical process that leads to such conclusions. Namely: "induction" or "inductive reasoning". Please do not confuse this with "deductive reasoning" used in mathematics!

Inductive reasoning is employed to formulate laws based on limited observations of recurring phenomenal patterns. While past observations of these phenomena provide certainty that the formulated laws work in the past, there's no guarantee that they will work in the future or for unobserved phenomena. This is the main reason why great philosophers like David Hume and Karl Popper argue its validity and call into question empirical claims made through the scientific method. Basically, don't mistake an inductive law for the truth!

But amateur philosophers fall into yet more traps:
- most of them do not employ the scientific method in the first place; while this method does not guarantee they will find the truth, it helps to increase the degree of certainty for their hypothesis and in most cases it will infirm it.
- humans suffer from the confirmation bias and most of us fall victims to it; we only need to see a handfull of instances confirming the hypothesis to be convinced of their truth, no matter how many other instances infirm it (we will even consider these as anomalies in order to exclude them)

My conclusion (drawn through limited observations and employing inductive reasoning) is that sufficient empirical evidence to support these rules was not presented. Even if they had had done so, do not mistake it for the one an only truth (remember the Black Swan). Remain skeptical and try a hypothesis several times before you become convinced.

Being software developers you should know that there can be more solutions to a problem. As a perfect example of this is the Gang Of Four book that just gives you some solutions to a handfull of problems. You have a choice of which one to use and the book presents advantages and disadvantages to using each of those solutions - these came from real world experimentation. I don't see advantages and disadvantages listed in the SOLID principles; I don't know how good they are and if they mitigate the risk of bad design!

On a different note, if everyone would be following a set of rules, is there sufficient room for innovation?

Nice article, reminds me of this nonsense

http://www.ssw.com.au/ssw/Standards/Default.aspx

My personal favorite:

http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterPA.aspx

Ferengi nirvana!

I agree that you shouldn't be a Ferengi programmer as you describe it, but I've never met one. Which makes me wonder whether we're actually disagreeing about something else.

@AJ:

Oh, man! SSW has good intentions, but seems a tad overly prescriptive.

@Mike G

SOLID is a set of OO design principles, not rules, and while I agree with your points of philosophy and science and induction, they really don't apply here. Yes, it is a problem, if people think these principles are some kind of universal truth, but that is hardly something to blame on a set of principles, is it?

The SOLID principles, while collected in the written work of Robert C. Martin, are not the experience of him alone. Robert C. Martin is just one of the guys who captured and described it. You can pick any textbook on OO design, and be able to see the same experiences and principles laid out there, just described in a different way. SOLID has become popular exactly because they boil down to the essential principles with which you can judge the quality of a design. These principles are gathered from many people over many years. Dismissing experience with an argument about missing empirical evidence is just far off, e.g. you don't argue about missing evidence when a craftsman criticises another craftsman based on good craftmanship which is the experience of the trade as a whole gathered together over the years.

I also suspect alot of people missed the point that these principles really are just OO elaborations on the good old (familiar?) design principles coupling and cohesion. Is it really that difficult not to recognise this?

SOLID principles are not patterns either, so there is no discussion of advantages and disadvantages of course. You don't need much experience to judge the quality of the principles yourself. They are about what makes a good OO design, not so much about how to mitigate bad design, although you can certainly use them that way.

Principles don't prohibit innovation, how could they? Principles don't prohibit thinking. People can innovate and think for selves and use principles just fine without any problems, given they have been encouraged to read and think of course, but if that's not given, you have bigger problems than using/not using some set of principles.

Jeff Atwood wants us to think about our work without getting too locked up in principles and rules. Sure, fine, I agree wholeheartedly, but he sure picked a bad example and a bad way to show it, suggesting that he's actually thinking only very cursory about the issues, which seems so typical for blog articles, but I still think a minimum of professional courtesy is in order, rather than blatantly making a small point at the expense of solid advise and experience offered elsewhere.

As far as "instructions on a paint can" goes, they may have their value, probably to begin with, but I can only say that if people aren't that prepared to read and study about what they are doing, I don't think they should be doing it at all. This may seem harsh, but it's not really. I don't have a problem suggesting that a little professionalism, and a little pride in the business we're in, is in place. Other businesses have this too, and to a much higher degree even, so I don't think I am out of line suggesting this. That's why it's just so out of place to point a finger at SOLID which has nothing to do with these "instructions on a paint can".

Imagine this was 1979, and Jeff had argued against structured programming and the design principles of cohesion and coupling, because the types of developers who could benefit from them aren't a) thoughtful enough about their work to care and b) won't read much of anything, and that "instructions on a paint can" to the 1979-programmer would be better in some sense, then maybe it's more clear why it's so out of place what Jeff is saying.

@Jeff Atwood
"The types of developers who could benefit from SOLID a) aren't thoughtful enough about their work to care and b) won't read much of anything."

Wow, that's a bit harsh on someone just starting out, don't you think?

Actually, the list is shorter:

The types of developers who could benefit from SOLID
a) Any developer who doesn't understand and apply them

What anyone writing in an OO language should be asking themselves is this:

Does *my* code live up to those guidelines? Should it?

If the answer is yes, then they're surely a good thing, and you can have no quarrel with them. If the answer is no - to either question - then you have some more learning to do.

@Jeff Atwood
"If we treat young developers like they can't think for themselves, then they won't!"

But it's equally irresponsible to make them learn everything from scratch.

I'm not sure why you (and a lot of other people) can't grasp the fact that these things are merely guidelines. There is absolutely no question that programmers need to understand and apply them. They also need to learn (possibly by guidance from better programmers) when they should not, of course. But that's step number 2.

My own experience is that people who do not program along those lines write crappy, unmaintainable rubbish. Furthermore, those people usually either

(a) can't tell that they are writing crap, or
(b) can tell, but come up with excuses like "the customer made me do it", or "developers need to think for themselves" (no, this isn't the first time I've heard that excuse) in order to deflect attention away from that fact

There is no downside to good design, people. It doesn't take longer to write good code than bad (it's usually quicker, both upfront and in the future). It doesn't take longer to write (sensible numbers of) unit tests - you'll get a payback in a matter of days, I promise.

Stuff like SOLID, design patterns, unit testing, refactoring etc are the basics of your profession, every bit as much as knowing about programming language constructs, or algorithmic complexity. You cannot be a competent developer without this knowledge and the skill to apply it.

Responded here : http://blog.dhananjaynene.com/2009/02/an-experienced-programmer-doesnt-use-solid-as-a-checklist-he-internalises-it/

@Petar Repac: "It seems that what are you saying is "read few instructions and go code", and learn on your mistakes.I agree that we all learn by doing and learn on our mistakes and get more experienced."

As Jim Horning said, "Good judgment comes from experience. Experience comes from bad judgment."

Not exactly what I expected to read at coding horror Jeff. I have been reading your posts for a couple of years now and found your thought process quite sensible.

Not this time though. There are far too many blokes, seemingly intelligent otherwise, who beleve the only things you need to learn about programming are looping constructs and conditional statements. I have had the misfortune of having had to maintain some really complex systems built this way. Learning the principles, are a must.

One thing that I think about when we as programmer are "bending the rules" is that it's a bit like genetic mutation. A lot of times nothing happens and nobody cares. Sometimes something bad happens. But much more interesting are the times when a mutation happens and something good happens. If we play by the rules 100% of the time we'll never have a chance of encountering a "good mutation".

John

I think people are missing the point of what Jeff was trying to say. He didn't say never use them. He's saying they shouldn't be a hinderment to development. It all comes down to academic theory and real life practice.

Personally I try to endever to the principles when I can, although I abhor engineering for engineerings sake. Sometimes you don't need a sledgehammer, when a pin hammer will suffice. And not all projects need engineering the the n-th degree, a lot of times, the KISS principle should override all.

I believe in unit tests, although I practice what I call Test-After. At a certain point in a developers life, you can code most requirements with very little defect introduction and test first or test driven slows the process down. IMO, going in after the fact and proving that the code you just wrote is defect free allows for a lot greater freedom in refactoring and edge condition testing but doesn't eat up as much time, refactoring your refactors. But at the same time, I've had 100% code coverage and had huge "defects" due to poor requirements and/or upstream services providing faulty data outside of my control.

I've worked at places where they've taken the principles to the N-th degree. Where it was the religon and if you didn't drink the coolaid, you were in trouble. They required 99.999% code coverage on everything that could be coveraged, at the time of checkins. Clover reports were generated on EVERY check in, by EVERY developer (They would sometimes get queued for hours and you wouldn't get reports till the next morning.)

Code reviews were done randomly and you were questioned why you didn't use this princlple here or why you didn't see that you could use that principle there. What Pattern you were using and why and why any other Pattern wasn't choosen.

It made development a chore and I love to code. But when you are more worried about what Pattern, Principle and your code coverage, instead of the quality of your code. Make the code work any way you can and as you go in later to test and refactor you can apply a lot of the principles where needed, when you need them, but you don't have to live by them.

My rules:

1. Understand the principles that others prescribe.
2. Throw those principles out.
3. Make your own set form the principles that make sense.
4. Don't ever stop refactoring the way you approach your craft.

@Paul

> I believe in unit tests, although I practice what I call Test-After.

The idea of using unit tests is that they should be written before the implementing the code. TDD/BDD states that the Design of the system should be driven from the tests. That is the main purpose. If you dont write the tests before implement the code, then you should not write them at all. Writing them afterward is a big waste of time.

> I've had 100% code coverage and had huge "defects" due to poor requirements and/or upstream services providing faulty data outside of my control.

Good point on the test coverage. The ones that says that 100% test coverage means zero defects do not know what they are talking about (some do).

> But when you are more worried about what Pattern, Principle and your code coverage, instead of the quality of your code.

You are right, the main interest should be the quality of the code, and that is why the principles are used. IMHO, having the SOLID principles in the back of your head increases the quality of the code.

Rules aren't principles. If you have no principles to guide you, how do you evaluate options or judge opinions?

There's a middle ground between Ferengi and Reaver.

http://en.wikipedia.org/wiki/Reaver_(Firefly)

The more I think about this, it strikes me that coding rules/principles/guidelines are like scaffolding for new developers. They're there to help out until you gain enough experience and judgment to stand on your own.

What I think Jeff is arguing against are two distinct pathologies:
1. Refusing to take down your scaffolding. Eventually, a developer needs to move beyond the rules and start using their own judgment and experience rather than relying on other people's prescriptions.
2. Putting a huge amount of effort into building a massive, perfectly crafted piece of scaffolding. The scaffolding isn't the point, the building is. Scaffolding should be as minimal and lightweight as possible. The more effort you spend on scaffolding the longer it will take to develop th experience and judgment to do without it.

Now I understand how you managed to achieve a 100% overrun while developing something relatively simple like stackoverflow: you are a cowboy programmer who likes spaghetti code!!

From: http://www.inc.com/magazine/20081101/how-hard-could-it-be-the-unproven-path_pagen_2.html

"Jeff kept telling me, "It's going to take six to eight weeks." I knew there was no chance that would happen, given that Jeff pulled his timeline completely out of thin air, but I humored him. In reality, it took about twice as long as that, which wasn't that bad, but it was still a 100 percent overrun."

As long as this is your own project that's fine, when you start asking money to customers for this, well, that's another matter...

I have a rule that anyone who strictly follows a rule is an idiot!

Hopefully noone will read through all the comments and see this. I wanted to comment the post: As a student in a system engineering class I probably shouldn't listen to this post ;-), but it felt relieving to do so. Having so much about different Methodologies (all words and concepts and practices and rules) and not seeing them in practice if they do work, it was a nice reminder that it is not "rules", but should be accompanied by thinking.

"The idea of using unit tests is that they should be written before the implementing the code. TDD/BDD states that the Design of the system should be driven from the tests. That is the main purpose. If you dont write the tests before implement the code, then you should not write them at all. Writing them afterward is a big waste of time."

Unit tests existed before TDD/BDD, so just because those styles of development "state" something, doesn't make it true.

Practically all code benefits from unit tests regardless of when the tests were written.

Blatant copyright infringement on that image, Jeff; no claim of fair use under US copyright law, either.

The problem with SOLID is that many of those principles have to do with class dependencies and responsibilities, particularly in terms of future expansion. That sounds good on paper, but I've never been on a project where our expected direction even remotely matched how our needs actually evolved.

For example, creating an interface for a class makes sense only if you know which functionality is generic and which is specific to your implementation. But to know that you need experience with several real-world use cases for your class. If you guess wrong, you're supporting two copies of your API, one of which is at best irrelevant.

SOLID makes sense if you're working in the world of detailed project specifications and large development teams. In that case, a careful OO architecture is useful, particularly so you can divide the work up among team members. If you're on a small team, maintaining a clean internal API is far less important, because changing the API is cheap and easy.

In my case, it makes more sense to first build a small, easy-to-read code base than have a clean, modular architecture. But as the code base grows and matures, and we learn which parts of the code change all the time and which parts never change, we evolve the code into a clean, modular architecture.

I once heard about a fairly large software company that maintained rules for *everything* They published those rules on their public site for the benefit of others. All of the rules I looked at seemed great, and I thought it was a good idea.
A while later I wanted to go back and check the rules out. The company no longer existed.

"Jeff: Yeah, it's a balancing act."

Rock on. Has balance been made a "principle" yet? If not, it should be.

Wow dude...!
This is serious! The stuff you're bashing here is roughly the foundation of programming as an art form...!
Sure you might be right that one should care more about creating then to read up on rules and philosophy about creation and such, and I also think that by actually creating you will learn more about the act of creation then by reading about it and all that stuff. But when you have done your fair amount of creation and you read stuff like for instance LSP and such you will realize that if you're breaking LSP you're not really building SW but rather in fact *_MUD_*...!

Though when you've done your fair amount of creation you will realize that for instance LSP is *right*...! There is NO WAY to make a square inherit form a rectangle, but if you've done enough creation you don't need to read it, you will *know* it and it'll become a part of your autonomous nervous system. These guys though were actually smart enough to understand WHY it was right to do thinks "this way" instead of "this way" and also smart enough to put NAMES on their principles and they recognized the need to write down these findings so that those that follows their generation didn't have to spend 20 years to acquire that knowledge...

To me here it sounds as if you're had some serious debates with a better programmer then you who have been referring to these principles to prove you wrong and you feel an urge to prove him wrong to make yourself appear right...

*SAD*...!
That's the only word I've got for you; *SAD*...!

What's next, Alan Turing was a dork...?
You're not a great enough developer to write about these things in the way you're doing here, sorry... :(

This type of discussion, or more appropriately "disagreement", says a huge amount about our industry. While everyone is focused on who is right and who is wrong, I think the underlying truth is far more relevant:

http://theprogrammersparadox.blogspot.com/2009/02/maneuverability-and-sales.html

Paul.

Uncle Bob > Jeff Atwood

Not saying that Bob Martin is infallible or I'm his psychophant, but
Bob's experience is far greater than Jeff's, so I'm more inclined to listen a bit harder to what Bob has to say.

Beyond that, I also have 20 years of experience myself and my own experience tells me taht SOLID principles aren't as disposable as Jeff is suggesting.

Software engineering isn't "wash, rinse repeat." Actually, you need to get a few people in the room to argue the semantics of the repeat operator!

Please, take a look at:

http://www.infoq.com/presentations/principles-agile-oo-design

I think you will find his arguments persuasive... Remember that these principles are a tool. Sometimes the tool doesn't fit the job at hand. Fine. Don't use it.

Remember that not all of us are building a web page in the latest greatest web-framework, and we need good practices to keep our code clean. :-)

Chad Moran wrote:

"I don't need a set of rules to help me make sure my product is flexible, reliable and easily maintainable. I can do that with my own judgment and insight."

OH REALLY? From your blog I see that you are 23 years old. And with that infinite amount of *professional* experience, you feel qualified to basically say "Hey..I'm so damn smart, I don't need to listen to anyone else's advice"

Your insight and judgement is not perfect, not honed and certainly not very experienced at the ripe old age of 23! You have much to learn my young programmer.

"I just hope others finally realize like I did that these rules really only hold back the experienced programmers."

That statement is so laughable it barely warrants a comment. Experienced programmers? Who is that? You? At...23? Dude..really..get a reality check. You don't have enough experience to really know. You might know tons about specific topics, but unless you were consulting for large companies in elementary school, you just don't have enough real world experience to understand what the hell you are talking about.

Here's some advice that I'm sure you will ignore. It comes from someone that has been doing this for A LIVING for over 20 years: If you don't have at least 10 years doing this for a living, then please don't tell someone who has that you are smarter than them. You might be right, but the odds are certainly not in your favor.

I wish I could read all the comments here but they are too many! So many man/woman/monkey hours... gone for ever! Is there a way to distil their wisdom and offer it in the form of another post?

Please! Work out a way! Maybe just find some guest writters who are up to this amazing task. Then, the new post based on the old comments, will attract new comments which will need to be distilled to a new post again. With enough iterations we will be able to condence all the wisdom into something as thick as dark chocolate.

Then, you will be able to make the move from programmer to chocolateer.

Sorted.

in 'agile software development', bob specifically states that the SOLID principles are not prescriptive rules for developing your software. nobody in their right mind builds software that aims from the start to adhere to the interface segregation principle, for example. the point is that these principles *often* help when your codebase is getting intractable - when you need to add/modify some functionality and it's harder than it should be. at that point, a newb thinks "ah well, i'll just hack it" and ends up making the codebase even worse; an experienced and capable dev thinks "how can i change this code so that it is more receptive to the idea of change?" and then refactors. that's when it often helps to think in terms of the SOLID principles and various design patterns that can improve the flexibility and longevity of your codebase.

>> This type of discussion, or more appropriately "disagreement", says a huge amount about our industry. While everyone is focused on who is right and who is wrong, I think the underlying truth is far more relevant:

I agree. I was a bit a hesitant at first but I now I am convinced by just reading the comments here. I made up my mind. I think I'll start writing my own methodology too so that I can:

1. sell my idea to developers
2. be popular on the web
3. be an author of "religious" books
4. get very high paying consulting jobs

...developers these days doesn't know how "THINK", yeah, that's the name of my methodology/technigue/principle/guideline or whatever. My "THINK" methodology doesn't require for paid training or using tools. It only requires developers to use common sense.

Oh, and it doesn't require 100 years of experience too. :P

Jeff,

The SOLID principles are a silver bullet; you should know that.

</sarcasm>

I wanted to through my iPod out the window when listening to that Hanselminutes podcast. I can't believe that Scott didn't challenge him more on this draconian rules.

You can't quantify programming into a set of finite rules, otherwise, we could just write a program to write programs and we'd all be screwed.

My $0.02..

Very nice post. In any field of endeavor, one moves along a continuum from novice, to journeyman, to master. Along the way one needs different sets of rules. Novice cooks need rigid recipes that they follow religiously. Journeymen know just enough to tweak the recipes when they don't have enough allspice on hand. Masters don't need the rules anymore at all. They are baked into their every decision. They know when it's okay to 'break' them and when it might be okay to create some new ones. I see principles like SOLID guiding individuals toward being masters (but only masters will know how malleable the principles really are).

The whole software industry has gone tits up! Complexity syndrome, noise, learn this learn that, experts everywhere, and there is simply just too many developers out there (and more to come) to even; a) make a decent living b) be happy with what you’re doing. Listen to the guy whom mentioned considering a career change, he knows what he’s talking about.

To dismiss rules, principles or guidelines that have evolved over time, requires you to have fully understood and mastered them by trial and error.

SOLID is a decent set of principles for writing maintainable and reusable OO classes, but as with any set of "rules" - you need to adapt to the current problem and select the right subset of principles to apply.

A novice developer that don't pay attention to "ancient wisdom" will waste a LOT of time, reinventing or rather - rediscovering the mistakes of others.

Study, absorb, apply, adjust, improve.

"The types of developers who could benefit from SOLID a) aren't thoughtful enough about their work to care and b) won't read much of anything"

I benefit from SOLID. I am thoughtful about my work. And I read a lot. I even bought Uncle Bob's latest book. Do you have a book I can read?

Although I appreciate the need to question everything, I hope you can acknowledge that we should all be questioning what you are saying as well. I think what you are saying deserves to be debated.

Where can I find some code you have written? Do you participate in any Open Source projects? Let us put your code where your mouth is, shall we?

First of all, who said anything about rules? These SOLIDs are principles and not rules. You can follow them or not, nobody is pointing a gun at you if you don't. You may even disagree with them, but then you should point to some concrete things you find questionable. Just saying "why should we follow rules" doesn't really tell anybody anything.
I myself have only recently encountered SOLID principles, but I find them insightful and also complementary with the recent(?) trends and techniques in .NET towards using IoC containers and similar stuff. And those principles are a good introduction for novices into a world of manageable and quality code.

Jeff, my feeling is that you just felt the need for a response to Uncle Bob's rant on his blog, which is OK, but I think in this case you're off the mark.

Funny to say that programmers that follow these rules are bureucratic or hasn't written a lot of code.

On the project I'm on now, we're about 20 developers.. Currently, we've ended up doing brute force development. Some uses principles, others not. Noones enforcing any rules. We've ended up with an extremely fragile codebase.

More fule for the fire:
http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-development-principles-in-motivational-pictures.aspx

People use to say that the truth is somewhere in between. In many cases that is not true (1+1=2 even if some people would says it's 3) but in this case I believe it to be true.

Buerocratic rule based programming will not work in the real world but still many of the principles are good. I find it interesting to read about different views of how to design software and I am sure that it has helped my thinking and programming skills. I would not however dream of trying to identify a rule for every problem i run into. And if I end up in a debate with my fellow programmers about how to solve a specific problem I do not think that "according to rule number 47 of this book..." is a very good argument.

I'm a bit conflicted. I've heard Bob Martin speak and he's terrific.
I agree that "rules" suck, but I've read and worked with a lot of code that would have been better if someone had read the rules and tried to apply them. I also find it interesting that Joel, who likes to see his software designed and planned down to the number of hours per task, wouldn't want to give people a good starting place for their designs. This is equivalent to nearly everyone "reinventing the wheel", which despite a previous post of yours is not a good idea for EVERYONE to do.
As the years pass, many of the old-time leaders of computing talk about the randomness and unpredictability of software projects. It's still an art and not engineering. Bob Martin et. al. are trying to take us closer to writing better code.
You, Jeff, frequently admit that you're just as crappy a programmer as anyone else. Why don't you try applying some of these basics to your coding routine and see if you don't improve?
I freely admit that I don't use some of these rules and haven't studied them or the design patterns in great detail. They're on my list of things to get to eventually. If I do any of these things, I'm doing them from past experience, but shouldn't we all try to improve our coding capabilities?

I suspect that full-time blogger and dont-follow-any-rules-just-do-it Jeff Atwood has a dwindling readership.
He comes up with an idea about flaming a few well known and respected figures in the industry, figuring that, while he may make a few enemies and spin a lot of crap (and drag in a few of the uneducated yeah-we-do-that-too brigade) he may be able to generate enough hoo-ha to re-ignite popularity.

I would attack Jeff's spiffy paint-can points, but the Straw-man tactics make the whole exercise a waste of time... A "Straw Man" tactic is where you make up an imaginary target ("SOLID are a bunch of static rules that prescribe exactly how you should program"), attribute it to an important personality, and then knock it down, pretending that the argument your thrashing, is actually theirs.

Reply to all those who say that SOLID are not rules intended to be followed to the letter:
Look up "principle" in the dictionary. A principle is "a basic truth or law or assumption". It does not mean "useful advice". Obviously a principle is something to always be followed.

So there are two possibilities:
Either the whole "you misunderstood Uncle Bob" mob is wrong and trying to invent justifications for Uncle Bob,
or Uncle Bob has problems with his English. In which case the same mob is wrong in the "don't criticize something you haven't read" criticism, because you can't seriously expect Jeff to read U.B.'s book just to understand how U.B. misuses words.

I wonder; do mathematicians of physicists reject the various principles, theorems and tools they have to learn in order to master the science, because they are ...too many or too hard? Why most programmers do? The moment they're presented with a few principles that attempt to instill some ounce of sanity and method into the profession, they bitch about how hard it is to follow them, even though they barely take a look at them.

Maybe that's why programming is not a science right now, eh?

I agree with the premise of your article -- any set of rules, however broad they are, and regardless of how sensible they are, can always be replaced with testosterone and arrogance.

Machine doesn't care how you code, only people do.

What's the difference between a 100,000 line monolithic app versus an object oriented one spread across many classes and interfaces to the a machine?

Machine is not baised toward patterns or code organization, it just compiles and runs.

Only humans care about Patterns, Practices, Principals.

Who do you talk to when you code? The machine or the humans? The machine.

So, maybe that's Jeff's point.

However, trying to make you code readable and maintainable for humans is a big challenge and that is where the pattern, practices, and principles come in. They should be there to help and guide one toward coding nirvana.

No one likes debugging, maintaining, and fixing obscure or spaghetti code.

Jon: I think the machine does care how we code but and sadly most high level programming makes the machine sad. If you code DSP algorithms or number crunching algorithms in assembly you try to avoid cache misses, pipeline stalls and stuff like that. That makes the machine happy and keeps it fast and cool.

Andrew

I remember Uncle Bob's OOD principles from when they showed up in the magazine and I was surprised to find out that some people are now viewing them as a methodology. I think naming them with a catchy acronym was a bad idea.

I believe that Bob's principles, LSP and GOF patterns belong to the canon of object oriented design. You may like them or not and the state of the art has progressed but a software engineer ignoring them would be like an English major who has never studied Shakespeare.

> Is it even possible to write software with no rules?

Pretty much. Check out thedailywtf.

@Lev

Please read the entire dictionary entry again:

a determining characteristic of something; essential quality.
or
A basic or essential quality or element determining intrinsic nature or characteristic behavior

It is completely disingenuous to start with Uncle Bob's SOLID principles as the header to a rant against too many rules in software development. If you don't understand those design principles it doesn't matter if you use a code repository and can build several times a day. You are still going to end up with unmaintainable crap.

Anybody who has a clue knows this.

Programming is a subset of Logic which is a subset of Philosophy. It is not engineering, it is not mathematics, and it is not an art, it is philosophy. One would be better off studying Socrates, Kant and Miyamoto Musashi than following rules, any rules. SOLID is a philosophy and to be studied, maybe used maybe not.

KISS is my philosophy, perhaps not everyone who is reading by no means. Hey if we get to tell people what they have to do, here is my draconian law. You are not a programmer if you can't write Assembly. Learn Assembly!

Did you just read that and think "that is stupid". Maybe other people has read your comments and thought the same. :)

@Mikeman
"I wonder; do mathematicians of physicists reject the various principles, theorems and tools they have to learn in order to master the science, because they are ...too many or too hard? Why most programmers do?"

The problem with this analogy is that programming is not a science. It's not engineering either. Programming is more like art or writing. Do artists reject the rules of composition? Do writers reject standard structures and styles? Of course they do. Sometimes this rejection results in an awful looking painting or incomprehensible prose, but sometimes it results in a great story or a groundbreaking work of art. Following the 'rules' is not a prerequisite to creating something good or even great in either of these fields. Programming is similar.

Andrew:

It is true, the machine does care. Nowadays the average programmer is so far away from the machine due to frameworks and abstractions that optimization at a low level doesn't really exist unless your writing a missile guidance system in C or even at a lower level in assembly.

For the majority, programming is:

SomeNameSpace.SomeClass.SomeMethod(SomeArgument);

Without Intellisense I think you would be down to a handful of hardcore programmers.

@Jon thats why we got the nice title of software developers. We don't program anymore. While I can program, I to am a software developer.

@Christopher

>> The problem with this analogy is that programming is not a science. It's not engineering either. Programming is more like art or writing

Hmmm... really? So when you type for (int i = 0; i < 10; i++)..., you are really expressing your artistic emotions of the day?
So what exactly IS science/engineering then? By the same token I could say that building bridges or making wash machines is an art. Maybe, but I wouldn't want to drive over such a bridge or wash my clothes with such a machine.

So DailyWTF is just a growing art collection of free-spirited avantgarde artists breaking new grounds? :)

SORRY....

I actually posted this on the newer post... just had to vent about the SOLID or AGILE or whatever u want to call it these days......

But for example, I find it interesting that after the brouhaha of stackoverflow # 38 (or whichever one it was), when you guys invited the fellow you criticized on the show....you would think that he would have come equipped with some decent examples, case studies, or......something. I thought Joel was extremely restrained during the interview, because at least for me, I totally didn't see his point. His appearance only solidified my belief that joel is more correct on this particular subject.

Look at the history of software, methodolgies, etc... AT LEAST 50% of it is either useless, self serving, or of no productive consequence, but when you dare criticize a methodology, the proponents act as if you are trying to stifle innovation. Where is the intellectual humility on behalf of the proponents of the new methodologies? And, when you are given massive exposure on a popular blog/podcast, and you can't find a remotely real world applicable example of why I should take your methodolgy seriously, you call me uninformed?

If I have a task to implement at work, I can write it with my present skills, it will work for years, and when a junior programmer comes along, they can figure it out. Following some of these "new and better" programs, it takes me hours to sort through how to disconnect from all the other objects, and no one will ever be able to figure it out.

I think Joel is EXACTLY right, I think these advocates are full of it. He can't really say it now, but I will restate what he said...I don't think these people write code day in day out. They live in a little fantasy land. They come up with their schemes in an environment where all the developers are hardcore and totally up on the latest design. Well, in the real world, everyone isn't. And who knows what developers will know 10 years from now. In the real world, designs and patterns come and go. But common sense doesn't. How about simple? I could show you code from the Thoughtworks drones that should be f*cking illegal. I've personally ripped out their crap and reimplemented smaller, simpler, faster, and more functional, with 70% less code.

I just don't buy the snake oil you guys are selling. (This is directed to the guy Joel hacked on.)

I read the list, and though I can't say I've read each of the PDF files, the "rules" in this list seem more like obvious best practices for any programmer who has spent any time writing object oriented software.

Using the paint can analogy, I would say the rules would read something like:

1. Paint the inner parts first so you don't leave thumbprints.

2. Use multiple coats to avoid runs.

3. etc.

It's not that seasoned programmers read and follow all of these rules. They simply already know them (often having acquired them through the process of trial and error).

You certainly don't need to follow all of the rules all of the time, but you're a fool if you think you can build quality software without making yourself familiar with the hard-won wisdom of the veterans.

So I just did a quick search of the comments here, and no where is the word "elegant" to be found. I seem to recall hearing that word a lot in the past when these kinds of issues were discussed, so its absence is interesting.

"Elegance" is a rather fuzzy concept, but it is at the core of what makes good design -- in software as well as many other things. And it is this eye for elegance (or beauty if you will) that I believe really cannot be learned -- you either have it, or you don't.

Lev wrote:

"Reply to all those who say that SOLID are not rules intended to be followed to the letter:
Look up "principle" in the dictionary. A principle is "a basic truth or law or assumption". It does not mean "useful advice". Obviously a principle is something to always be followed."

You are wrong. You have to take context into account when you look up a word in a dictionary. Jeff is talking in a context of software construction and engineering, not some scientific discipline.

A principle is only a "truth" or "law" in natural science, i.e. when we are talking about a scientific principle (e.g. physics or some other scientific discipline), not a principle of construction quality and dependency management, which Robert C. Martin's principles really boils down to.

When I argue for thinking, it should go without saying that if your applicaton of a set of principles leads to more code or rather than less or worse solutions, you should reflect on your use of those principles, and whether they are applicable in your current situation or you're using the principles wrongly. Principles can guide you if needed, but of course they can never replace independent thinking.

If you boil it down to KISS, DRY, "Generality, Clarity and Simplicity" (all of them good) or some other thing, we are just talking about a different equally applicable set of principles, but that has nothing todo with applying SOLID wrongly, or applying SOLID at all, which talks about dependency management. You could see SOLID as a natural elaboration of a simplicity principle in a certain context. This is what makes Jeff's arguments so far off, because he misrepresents the SOLID principles.

Another and even more high-levelled thing. If it becomes drone work, drudge, slavery, robotic, and such to follow a set of principles, killing all mirth and fun of your work, it's definitely time to reflect upon the use of that particular set of principles. At that point you've learned something important, and it doesn't necessarily mean that particular set of principles is wrong, just that you maybe learned something, and are now moving along.

Personally I'm always on the hunt for the minimal, sustainable set of principles, and it's in a constant flux of change, and filled with conflicts, but it doesn't matter, because context usually takes care of those conflicts. Different contexts dictates different principles. It's always good to know about the common, if not fundamental, underlying principles in order to navigate around in the landscape of programming. I am certainly a better programmer for it, and as such any set of principles has just been a short cut for me to gain more experience more quick than not.

Of course, I continuously try to improve, and if people don't try to improve their work or maybe just do it plain good (no fancy stuff needed to do good work), then maybe they should do some other work. I am not sure, it's our job to cater to those, who doesn't read books or try to improve upon themselves and their work. I'd rather have them do something else, something they might even be good at, and want themselves to be better at. If many workers in the software business belong to that category which doesn't even familiarize themselves with what they are doing, we have a much more serious problem, which should be dealt with otherwise than thinning out SOLID principles to some barely sufficient minimum. I think Jeff is doing a disservice here to any worker in that category. If people don't want to improve, you cannot make them or reach them, and it's a waste of time to try to. Am I being too harsh here? I'm not sure, but I'd rather climb steadily upwards than being constantly held down by dead weight.

Hey, honey, lets only KISS cause I'm never SOLID

@Trevor

I bet you deleted the tests, too.

I think you may not understand those principles and therefore don't understand the value of them. The all have to do with architectural decision a programmer makes. Saying the rules of the language and compiler are enough doesn't really cut it. Knowing and understanding good programming principles and patterns is part of the growth of any good developer. And these are principles not rules, the rules are already built into the compiler. Even Bob will break a principle if the problem requires it.

Here... let me help you. I think this is more succinct:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

At least we're not arguing about how GO TO should be eliminated from all code anymore. That's progress.

Jeff -

I found much of this amusing. Dr Johnson said: "Clear your mind of cant." Many of your poster's minds seem to be straitjacketed by either religion or methodology. Statistics will tell you, almost everything you believe to be true is wrong. (90% anyway)

- Lepto

When I first start programming professionally, I had no clue about design principles. When I started seeing a lot of the code I wrote blow up in production environments and then see a ton of bugs get introduced every time I added one simple feature, made me want to quit. Then I did the right thing and started to read about programming and take an *Active* role in making myself better. Some of those design principles I figured out myself. Some of the TDD methods I figured out before I even heard what TDD was. Some of the OOP concepts I learned without even knowing that's what they were called.

I didn't go to college until AFTER I was already in the field for about 10 years.

Now I teach younger developers about these principles and how not to suck when I hire them because I'm now the manager...

You don't need a book about SOLID design principles to be a good software engineer. You need to think and learn for your self. Pick up a book when you are stumped or don't know where to turn next. If you are truly a software engineer, then you will get the most enjoyment out of the discovery, not the end result.

At least, that's how I see it.

This post made no sense apart saying that rules limit your freedom.
That is true, and also limit (slightly) the enjoyment of programming.
The reason is that the enjoyment you perceive comes from complexity. Sometimes I caught myself making my life a bit harder because I want to enjoy a bit more the programming. Not looking up at a solution or THE way other solved a problem straight away and trying some fantasy solution first is more fun. I agree here. But you should be a grown up senior programmer and live with it.
As a counterpart, when you do a perfect design at the start and follow good consistent guidelines (when and where you agree with them), you get a sense of cleanness and the software has a sense of wholeness that make up for the lost "enjoyment" for complexity. Which leads you into unmaintanable code. Also you have a sense of superiority to the 99% of bad programmers trawling around. And you have a quicker and better career.

Using good (and internalized) guidelines (for me are SOLID and DDD) give better and more maintainable results, this is an hard fact.
The more the software should be changed in the future and the bigger the size of the project the more you should stick to them. No questions here. For big software projects (that last many years and have continuos versioning) 90% of work is maintenance and coming up with new versions. You only build it once, and that is 10% of the time if you account a period of only 5+ years and built the first version in 6 months (common timeframes here). If you dont get it right you might even have to live with a bad design for all those years and be slower at improving your software.

I'm very happy many programmers like you don't understand this, I can keep being happy with my sense of superiority.

More fuel for the fire...read this post.

http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=25748

Jeff, I enjoyed this metaphor. I doubt you can really appreciate how well it touches reality like some of us, but spot on. Now...will you be getting sued too?

Thanks for thinning the market by saying things that will make rookie programmers dumber. At least I won't have to worry about competing against them in the market, since I will own their asses in every way.

I have to agree with you and Joel on this. Today most so-called programmers talk of design patterns without knowing when to apply which and more importantly when not to apply. They talk about agile programming not realizing their downsides in certain situations. Good programming is not by fixed set of rules, it is dynamic in nature and adapts according to external factors and internal constraints. People espousing big theories have normally lost touch with actual programming imho. More on it later but I am feeling tired now.

Hi guys. Do something every day that you don't want to do; this is the golden rule for acquiring the habit of doing your duty without pain. Help me! I find sites on the topic: kitchen islands. I found only this - <a href="http://kitchen-islands.info/Buy-kitchen-islands/Kitchen-islands-design-on-wheels/">Kitchen islands design on wheels</a>. Easily compare and save on cheap airfare. Our travel agents or travel agency will search the lowest discount airline tickets for your trip. Waiting for a reply :mad:, Nicola from Senegal.

Hey. Keep your broken arm inside your sleeve. Help me! It has to find sites on the: Search for best flight deals, last minute airfare and save big on your flight booking.. I found only this - <a href="http://kitchen-islands.info/Moveable-kitchen-islands/Custom-kitchen-islands-rugs/">Custom kitchen islands rugs</a>. Whichbudget brings you all the cheap flights with budget airlines in one place, linking over european. Payless for your airline tickets! Discount airline tickets. With love :mad:, Pin from Western.

Whoo this must be one of the largest religious shitpiles of the internet.

1. Never ever go negative on something you dont understand.
2. Use the right tool for the job. Regarding SOLID, It is just one set of tools in the programmer toolbox. It will like any other powerful tool kill a project if overly and wrongly used. It may also like any other powerful tool help a project if rightly used. So stop arguing and use the right tools for the job.

"...The Ferengi are a part of the Star Trek universe, primarily in Deep Space Nine. They're a race of ultra-capitalists whose every business transaction is governed by the 285 Rules of Acquisition. There's a rule for every possible business situation -- and, inevitably, an interpretation of those rules that gives the Ferengi license to cheat, steal, and bend the truth to suit their needs...."

WOW it sounds like my country, Italy, not a different galaxy, after all! ! !
ciao
Alex

really fantastic posting, that is so wonderful.