NAMBLA! HA! Nice followup Jeff :). It's a bit more complicated and mentoring sure does help people (such as the fine articles on this here blog).

Until now, I actually thought NAMBLA was something like KISS... :P

Perhaps I should've researched it a little sooner ;)

Don't understand NAMBLA....

Dummies have their place. They make me look better and raise my salary. Leave 'em alone.

And I can call them dummies, because they don't know that I'm calling them dummies.

well said.

Maybe you should call them the "four noble truths".

Wow, you should look at how this post is formatted on your feed, especially at the end. Looks wacky.

Yay for ignorance.

You know it's weird. Back in college I had some bright professor guy spend an entire semester teaching us how to mathematically prove the validity of our algorithms using First Order Predicate Calculus.

I've yet to encounter that anywhere else in my career.

North American Man Boy Love Association? (this phone doesn't get youtube)

I believe that's "National Association of Marlon Brando Look-alikes".

Yep, we've confirmed what's wrong with the other developers out there. Now, what do we do about it? What do we do when they're on our team?

Good post, Jeff. Not sure if marketing was the point of your post or not, but I think it's an important fact. Developers tend not to be good at marketing what they're doing, or they promoting good ideas is is "being pushy". For evidence, you need look no further than web development frameworks. Then compare them to RoR (whose creators are excellent marketers). Look at the rate at which the product and community have grown.

It's important if you're the guy that knows, to share it with your co-workers. Like you do on this blog. If you're working somewhere where that doesn't fly, seriously, what are you doing there? You're just a drone at that point.

Doctors don't last long without continuous education, and programmers shouldn't either.

No Politics, Please!

If I was to convert this into a fitness and exercise analogy ..

* There are tons of people trying to learn how to be more fit
* There are tons of exercise regimens to help them go down that path
* These messages will not reach most of the people wanting to be fit
* Many people won't actually get it even after the first 3-4 months
* Many of them do not even want to consult a physician (high consulting fees)

So to each of these folks make sure you DRY n KISS n think about fitness but YAGNI to all the other fitness regimens.

I can hear the message, understand the message, perhaps even grok it but cant quite buy it, cos I don't feel like giving up on ways I believe improve fitness.

In my experience the best way to get these developers moving forward is through pair programming. Often times, they don't know what's possible and seeing a very proficient peer in action is the best way to spark their interest. Also, switching pairs will spread this knowledge throughout a team. Most of the time this environment will encourage growth but if they remain a deadbeat the team will eventually weed them out.

Sure pair programming works. one guy does 90% of the thinking and one does 90% of the typing. The guy that does the typing complains about doing all the work while the guy that does the thinking gets an ulcer.

"If it can't be explained on a single double-spaced sheet of paper, it's a waste of your time."

I think this quote shows the problem with peoples attitudes about programming. Many problems are not easy to understand and not easy to solve. If you don't regularly come across things that take many sheets of paper to explain you're not trying hard enough.

Is this supposed to be a provocation or something? If not, please explain how the Open Closed Principle follows from NAMBLA.

Your religion might be comprised of marketing. But others aren't always like yours.

Please remove the word religion if you didn't want to talk about it or at least rephrase it so it's less insulting.

> If you don't regularly come across things that take many sheets of paper to explain you're not trying hard enough.

I'm not particularly sympathetic to Jeff on his points, but this is dangerous advice as well. Could encourage people to make unnecessary work for themselves just to make sure things are "interesting".

> Back in college I had some bright professor guy spend an entire semester teaching us how to mathematically prove the validity of our algorithms using First Order Predicate Calculus

Or further education, I presume? Probably not a mathematician, computer scientist, researcher, etc. then, eh? Just because it's not job training doesn't mean it's not useful brain and though pattern preparation. Nor does it mean it's not useful in someone else's computer programming related job.

You're kidding right? I LOVE programming, I love learning about design patterns and structure methodologies. But, my cranial RAM is full! I'm still trying to cache something...anything to my mental hard drive that I've learned over the last year!

WPF, Silverlight, SQL 200X, RAD, SCRUM, Agile, NUnit, TortiseSVN, TFS, VS 200X, AJAX, Javascript, HTML X.X, CSS X.X, PHP, C# X.X, .Net X.X ...duh...the list goes on and on.

All this progress is cute but I can't keep up...oh...wait a sec...thank you God, I think I'm having a heart attack.

Goodbye cruel world!

This is probably not the entirely appropriate forum for this rant, but I wrote it already....

Good point, I suppose. 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 think I'm gonna come out as well:
My name is David, and I can't stop thinking about programming

(typed at 8a.m. at the start of my weekend, when I woke up early and thought 'lets check coding horror and possibly work on a web app'... oh, and it's supposedly something called 'valentines day'?)

As for the A4 design idea... I don't think he is that far off the mark. If you don't understand an idea well enough to explain it in a single sheet of A4, you probably don't understand it well enough to code it... go away and gain a better understanding. I think this should be hierarchical personally, but a single sheet of a4 for each bit of the system at each hierarchy level sounds better than reams of prose and diagrams that took months to create, still don't give a decent explanation and that are so big that no one will bother reading them anyway...

So I guess we should stick to the 1969 structured programming then (or even something before that), since everything that came after is just too complicated to fit your "sheet of paper" definition. Objects, inheritance, encapsulation, overloading, interfaces, delegates, lambda expressions etc. - I could argue (using your 4 "rules") these are all unnecessary since you can achieve DRY, KISS, YAGNI with simple plain old C

I believe Jeff totally misunderstood the motivation for many of the fancy methodologies like RUP: it's not to make great programmers greater, but to reach the people who are not interested in improving their programming skills, not through marketing, but through simple coercion.

The idea is that a methodology like RUP, if allows a large organization with a mix of competent and incompetent programmers to have the incompetent ones be productive by establishing clear rules about who has to do what, and how to cope with problems that arise.

It's certainly arguable whether this works as well as the proponents imagine, but it's at least a constructive idea of how to deal with the situation of many large organizations DO have lots of marginally competent programmers and DON'T really have the option of firing them all and hiring only competent ones.

The software engineer should have as a minimum:

1. Membership of a society-wide accepted professional institution that is the governing body of professional software engineering standards, status and awards.

2. A computer science degree with a minimum of 25% mathematical (pure and applied) content acceptable to the above institution.

In my software engineering class I learn about all those methodologies and metrics. Then we go and do not ever use them again (heck we didn't even used in the first place, we only learned how it worked) in our entire academic life.

90% of my colleagues HATE software engineering class, there is simply too much information that we don't apply anywhere, Most only get all the slides the professor use one day before the test and study like hell.

Maybe if software engineering wasn't so boring we could have more interested people

I laugh! And it is funny because it is true!

It is a bit sad too, as there has to be a few more cold hard truths out there, but you certainly have to wade through some deep sewers to find them these days.

But that is not important right now - I want to start the first ARSUPP (Atwood Real System of Ultimate Programming Power) training center in my region. I expect I first need to pass the 8 week ARSE (Atwood Real System Engineer) training, so where do I sign up?

;-)

Sorry, what's the "NAMBLA" supposed to represent? Just a joke? Or something along the lines of:

"Just like NAMBLA can, and has the right to, attempt to legalise sex between adult and minor males. Similarly zealots and marketeers have the right to advertise their version of "The Methodology". But in both cases you still have to use your own judgement and make your own decision about going along or not?"

Brilliant reposte, Jeff. Couldn't agree with you more :-)

"But here's the paradox: the types of programmers who would most benefit from these guidelines, rules, principles, and checklists are the least likely to read and follow them."

Well let's take building for example: the types of [worker] who would most benefit from these guidelines, rules, principles, and checklists [for building houses] are the least likely to read and follow them.

So what you are saying ? That those that are not knowledgeable enought in X would have most benefit in learning X ? That just seems common sense to me.
So little value you are providing there.

"It's no coincidence that a lot of the proponents of these methodologies make their living consulting and teaching about them."
And exactly how is this different from you proposing us your visions about sw development on your blog and making money from that ?

"Remind me again -- who, exactly, are we writing these principles, rules, guidelines, and methodologies for? If we're only reaching the programmers who are thoughtful enough to care about their work in the first place, what have we truly accomplished?"

Let's try mathematics this time. Are you saying that mathematical discoveries shouldn't be written in books because they would make sense only to Ph.D of mathematical science ?

Sorry, but seems like another non quality post on otherwise very good blog.

Above, you quote Jef R who was replying my question, which remains unanswered.

I am astonished that you seemed have missed, possibly deliberately, that SOLID is about design! I also have noticed, some other posters here dont seem to have, that you have subtly changed your line of argument from :

podcast : agile is a waste of time, you don't need it
ferengi : solid is bureaucratic
this one : no point trying to improve programming technique as most people listening

This aside, can some please reply to my original question:

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

I think that ignorance is only a small part of the cause of the problem, and making the case that software developers simply needs to be educated is a convenient and simplified view.

Software developers might make an active choice not to use any principles/methods/methodologies, but instead go for the cowboy quick-n-dirty style.

Why?

In many cases the goal of software development is as simple as:

1. Make it work
2. Do it as quickly as possible

A lot of companies today don't compete on quality or durability. Quite the opposite actually, the biggest and most successful companies seems not to care so much about quality, and rather compete on other means. Such as low prices, aggressive marketing etc.

Why and how would the software industry to be an exception from these market forces?

R. Lee Ermey...

"This is my keyboard. There are many like it but this one is mine."

The Rational Unified Process was invented long before 2003 - I can remember using it in the late 90's.

Sorry, Jeff. You just don't seem to get it. And neither do a lot of your readers.

SOLID is not a set of commandments about how to write software. SOLID is about gaining an understanding about what makes an object-oriented design a good one. I agree with DRY, YAGNI, and KISS, but these ideas don't give you any guidance about how to design your class structures.

So what happens when you sit down and try to write code? Re-listen to the Hanselminutes podcast where Bob is talking about the LSP, and he gives the classic example of the Rectangle vs. Square class design. Nothing in DRY, YAGNI, or KISS will guide you in any way about how to create your classes here. The LSP (The "L" in SOLID) gives us a really good way of thinking about how we might design these classes, and also gives us a reason other than "well, it *felt* like the right design at the time". This, then, is the true value of a set of principles like SOLID.

These principles become more important as the importance and visibility of the software you write rises. So if you're publishing an API for other programmers, either in a large team or publicly, non-SOLID based object structures are visible to few people. Sure, you may find yourself having to spend a bit more extra time changing your code, but that doesn't matter as long as you or your one or two team members are the only ones making the sausage. I suspect this is where your (and Joel's) lack of understanding of the principles stem from.

Let's face it, SOLID is getting criticism from a guy who made his own "language" to wrap classic ASP, and whose company is now stuck with it. That's hardly a sign of someone who cares about the ability of other people to work with his code.

Now it's time to hold up the mirror, folks. Which ones of you who are criticizing Bob Martin and SOLID have written public object-oriented APIs, used by many people? Code bases to be used by many people in your team? Code that can be extended *without having to be changed*? Then you're probably getting away with ignoring these principles.

Just understand that getting away with coding something and having it work is not the same as writing good code. "Thinking about coding" is not the same as writing good code, either.

I don't like the NAMBLA joke. It's like "if you ask about NAMBLA then you belongs to that group, the unenlightened mass". Questions are the most important thing in our society.

Or is it joke about abbreviations? If it is, then you do not understand abstractions. And that is a crime.

Please, do not make me research unimportant things on the internet. And do not try to make me laugh!

Thus, if you read the article, you are most assuredly in the twenty percent category. The other eighty percent are not actively thinking about the craft of software development.

True.

Thing is, at least 95% of useful and functional software is produced by that 20% of people. The other 80% are not really in the business of producing software, they are in the business of 'sitting in an office'.

Say if you are interested in marketing products and services. These can be genuinely useful or snake-oil; from a marketing perspective it makes only a subtle difference.

If your products/services are, or claim to be, useful for software development, you aim at the 20%. If they are aimed at 'sitting in an office guy', then he is just a small niche within the larger set of people who sit in offices not doing much. The key products they require are chairs, coffee, and time-wasting web apps.

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

This is still wrong.

The statement above says,
1) Good principles will be enforced "see that good principles are followed"
2) Do not explain the good principles being enforced "without ... even mentioning those principles"

The lead or manager should NOT avoid mentioning and discussing the underlying principles he's expecting his team to leverage.

I suspect that success is much easier to achieve if it has been clearly defined.

"If you find yourself in a hole, the first thing to do is stop digging" -- Will Rogers

Jeff -- to me, these last couple of posts appear you're letting your ego argue for you. First you present a Ferengi strawman, and now a false dichotomy.

Sure, a minority of us developers actively pursue improving our craft. Sure, a lead or manager can attempt to force a methodology onto her team, and fail miserably.

But this ignores *why* a lot of fundamental change in our industry actually happens.

Change in software development comes from the trenches, and it uses the same mechanism that caused my Arthur loving little girl grow into an emo teenager. Peer pressure.

There was the geeky few who toyed around with C++ in a C world -- they sneezed on some others who caught the bug -- eventually the entire industry got sick ;). Then there were other geeks toyed around with Java in a C++ world, sneezing on their peers. Similarly, it was geeks who gave iterative programming a shot in a waterfall world.

And now there are some of us who've felt a bit of the SOLID bug coming on. We hope it's contagious.

Sorry, I don't get the Nambla joke. Would anyone care to explain, please? I am feeling quite stupid now. I guess this means that I definitely belong to those 80% inferior beings. No irony intended.

I don't want to mischaracterize what you're saying, but I interpret it, in a nutshell, like this:

* There are millions of programmers who are nine-to-fivers who don't care about there craft;

* These are the people who would most benefit from learning guidelines and method of some sort, but are also those who are least likely to learn them, or indeed even read about them;

I agree completely, but that does not devalue guidelines and methods that exist. And:

* Those of us who care about our craft and make an effort to learn need to carefully consider methods and guidelines, rather than adopting them blindly.

I also agree. I don't follow any single methodology end-to-end, but I do read copiously, try different things, and adopt those that appear to make a difference to my work and drop those that do not.

The problem, I think, is that for a lot of people what you are suggesting would amount to a license to disregard method and guidelines without the careful consideration and continuous learning that most people who care about the craft should follow.

My $0.02.

Sorry Jeff, tried really hard to post my comments here but since you don't allow HTML, the formatting came out wrong.

@Markle - Spot on.

Programmers are not the problem. The problem is the continual interruptions by management, marketing and sales people - who, all believe, that programmers can and should be interrupted at any time, work overtime with no pay, be subject to environmental conditions which are not conducive to creativity nor productivity.

When those road blocks are removed, then and only then will real productivity and creativity begin to emerge. Not any of this agile or scrum crap.

Ok, so we're suppose to keep our programming simple so we have more time to rape teen boys? Or, just have more time to joke about it? I'd appreciate if you could expound upon your last point. I think there are a few confused people here.

"And how do we expect the average developer to find out about these? In a word, marketing."

Through education, otherwise they have no business working as programmers.

"So, if we know the programmers who would benefit most from these rules and principles and guidelines are:

highly unlikely to ever read them of their own volition
almost impossible to reach through traditional religion/marketing"

Then those programmers should not be programming. Some minimum of professionalism is required, otherwise the business as a whole reflects this (and I think it does so now).

I think we would be doing these people a disservice by catering to them through any kind of marketing, except maybe word by mouth, but then that's how people always "woke up" and found out about how to do things better, or just new interesting things.

I think we can interpret Jeff's post in the other way around.

It's not that principles like SOLID are bad, redundant or anything, just that their goals are all the same. To educate developer to write a 'quality' program that easy to read and maintain. That's DRY, KISS and YAGNI.

Though, having so many principles to follow has some draw back. Some people just don't try to understand them well before using them. I've met some developers who are so zealous about some 'design patterns' and 'principles' and make their program an over designed piece of junk that suffered anyone who try to maintain it.

Maybe it's just that these programmers don't put enough effort understanding these 'principles', or maybe it's just that there are too many things for them too learn and make them forget the very basic things like DRY, KISS and YAGNI?

@Just Wow

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

Agreeing with the point Jeff is making is not the same as deliberately avoiding all the SOLID principles (or similar ideas that have emerged from software engineering experience over the years). It certainly doesn't mean believing that avoiding them leads to better design.

To me the basic point here is that there are no silver bullets. You always have to think about what you are doing, and if you should find yourself in a situation where breaking some principle gets the job done better, then don't be afraid to do that.

So "fundamentals" are OK but "principles" are bad?

I've spent years trying to increase acceptance of Agile "fundamentals" in developers with traditional OOP backgrounds. These people are not unreachable - they do read and think about software development, and their ideas have merit. Endlessly chanting "YAGNI!" will NEVER bridge the gap.

What can? Show them how design can evolve. Write clean, maintainable code using Agile techniques. Demonstrate how TDD reduces defects and enables refactoring. Understand and speak their language.

Doctors have to learn the Latin names of body parts, as those are part of the technical vernacular of the profession. "Arm bone" just isn't specific enough. Terms like "Strategy Pattern" or "Inversion of Control" can provide the same benefits to communication in our profession.

Jeff--

There is a huge flaw in your thinking. For programmer to know how to keep from repeating herself, to know how to keep it simple, to know she ain't gonna need it, and yes, even to love a boy, she needs to study and understand a core set of programming principles.

At the core of this Jeff I don't think you really believe what you are saying. You're baiting us--and man is it working. You've hit on a formula to generate noise about you and your blog.

StackOverflow is superb and I respect you greatly for the work and time you've invested there. As a blogger, though, you've become the technical version of the ShamWow guy. You're carnival barking for your brand.

Sincerely,
Roger Pence

@Jeff

I didn't recognise your acronym #4 and looked it up on wikipedia. For what it's worth I am upset about this attempt at a joke and I wish you hadn't done it.

I read quite enough vile twisted sick stuff in one day just by looking at newspaper headlines.

While I agree in general, the whiff of elitist backpatting does bother me a bit.

Various "methodologies" are not really about programming at all, and even the most brilliant "coder" can benefit from thinking and using them. There are many activities related to getting good, robust, code out the door that satisfies customer requirements, and in my opinion the "programming" part is only a smart part (just like "good construction" is only a small part of what makes, say, a successful automobile).

Sure there are common principles throughout. In Carlin style we could probably whittle these down to "be excellent". But the actual formulation of this principles into guidelines provides a framework that all parties (customers, programmers, testers, config managers, project managers, et al.) can understand and follow.

If it was easy as expecting people to just "do the right thing" we wouldn't have any of these methodologies and every project would succeed.

I think part of the problem with software development and the reason we're having these discussions is that the barrier to entry is just too low. Anybody can download some free tools, put together a program and distribute it widely.

Many people think software development is not an engineering discipline but a craft or some form of creative art. Would you let anybody step into your shop and use your table saw or your lathe? If so, would you expect that anything good comes out of it. I was watching Jacques Pepin one day and he said that after years of apprenticeship he "graduated to the stove."

And even if you agree software development is an engineering discipline, it's still way too easy to become undisciplined and lazy. The guy in the cube across from me designs plastic parts for our products. When he finishes his CAD work and releases the design we have a thorough design review. The mold guys get involved and figure out if it's ok to build a mold that costs hundreds of thousands of dollars.

Another guy is designing circuit boards. A board turn involves circuit design, PCB layout and fabrication and board stuffing. There's a huge cost and several months of cycle time.

Do you think the guys doing mechanical and electrical engineering should just throw the principles overboard and "do what feels right." Maybe just build a few molds and see how it goes?

If you answered "No" then why should it be different for software? Because the website or app you're working on will be obsolete soon anyway?

I'd rather be a software engineer.

Yeah, wtf is nambla with regards to software development?

This debate is way too polarized and I think the far ends of the spectrum would learn a lot more from each other if there were less loaded words being flung around and more seeking for common ground (my longer-winded way of saying this is at http://www.above-average-software.com/articles/read/the-goldilocks-principle). I find both sides of the debate hard to stomach at times.

In the end, I don't think you can't rely on successful people to accurately communicate why they are successful. Having Jeff or Joel or Uncle Bob or Linus or Anders or a lot of other successful programmers tell you what they think works, whether Jeff's "keep it simple" stuff or someone else's 98 page thesis on the best practices of writing generic mock unit test framework interfaces... they're probably wrong about why what they have done has worked for them. Trying to copy what they say they do is just cargo cult programming taken to a higher level.

The success or failure of software projects probably has more to do with management of teams than with the practices of the coders involved. I think it's more important that the team you're on share a philosophy and style than what that philosophy and style are.

@Console

Chill out man...it *was* a joke. And in my opinion, a good one...

You missed one - Brute Force Development:

http://softwareindustrialization.com/BruteForceDevelopmentBFD.aspx

"My name is Jeff, and I can't stop thinking about programming. And neither should you."

I think this can be misinterpreted.

You don't need to be obsesed, you only need to have a *professional* attitude. It's a drag when the whole business world thinks that if you program, then you are not a profesional but a mere worker.

The best material you need to learn is *not* wrote by Software "Engineering" academics (who profess this corrupt programmer-worker analogy), but by Software DEVELOPERS in blogs and articles online.

PS: sorry for my english.

PSS: Steve McConnell is a software developer. He just doesn't know it yet.

Hate to be a bitch, but...

Throwing a book of rules at a terrible programmer just creates a terrible programmer with a bruise // on their head // where the book bounced off. --> ...on his head...

Here's one thing that I think messes up these software methodologies: as with many other management methods, there are a few relatively simple good ideas inside each of the software management methods.

Unfortunately, it's hard to make a successful career as a consultant training people on a few simple insights. This is actually a shame, since it's often very hard to get people to actually use the simple insights, and successfully training them to do so would be a real success.

Further, you can't write a good book out of a few simple insights. This is why management books are always so full of chaff, anecdotes, and filler. It's hard to sell an 84 page booklet as a trade paperback in the airport bookstore, so the authors always bulk them out.

I'm painfully conscious of that from having watched a very large company grab up scrum, which seemed to have a few good ideas in it about how to react to the unpredictability of the software development process.

But the large company sent everybody off to scrum school, which dressed the simple goodness up in a huge mass of "stories," and "story points," and heaven only knows what all else, until they had ended up with something as bloated as any waterfall process from the 1970s.

Now that I am writing this, it occurs to me that another problem is that a lot of the broadly agile processes are based on having a small number of excellent programmers work very intensely together. But large corporations that buy into the buzzwords all end up mis-fitting them onto some variation of human wave programming....

@Roger Pence,

On the ShamWow Guy analogy; *wow* I think you have captured it PERFECTLY. That's exactly what I'm seeing.

I do think a lot of this Agile/SOLID etc stuff is problematic. I think "Uncle Bob" did a pretty poor job of defending his position.

Nevertheless, I'm worried that Jeff is advocating a very lazy view. I
ve seen this a lot lately. I think the views he has been expressing the past several months are like:

"Don't worry about having in-depth knowledge of anything. It's pointless. C is hard and performance is hard and probably a waste of time. Look, if you are reading this blog, you've already won the battle. You reading programming blogs, THIS BLOG, in fact, therefore you are elite. Congratulate yourself. Think about programming all the time; just don't think very hard, you might hurt yourself. Remember, you've already won!"

It just seems to be a very lazy view. Just because you read programming blogs doesn't mean you have knowledge that others don't. Even if it does mean that you have "passed" some "magical level" it doesn't mean you're right to just stay at the surface of everything. It just seems pretentious and self-congratulatory.

Jeff, this is so hypocritical. Go back and read your DRY post "Curly's Law: Do One Thing", where you actually quote from Bob Martin's Single Responsibility Principle. Now, I am really confused with you about you and Joel were arguing about in your StackOverflow podcast.

I agree with your general principle about not drowning in methodologies and principles, but what you seem to be recommending and what you have actually done are contradictory. You have actually learnt what works for you and use that.

Would you be a better programmer if you didn't learn everything you learnt over the past several years? If so, why are you advocating to others that it is a waste of their time.

I dunno what Jeff's trying to get at. But it seems to me that his three principles don't mean that you ignore all the other stuff out there -- just that those three are the core.

To my eye, SOLID consists of one iron-clad principle of OOP (LSP) and four great patterns for OOP development. But I have a huge problem with treating those other four as if they are the core of OOP, because they are only great patterns when applied sensibly, and the way I'm seeing SOLID presented suggests they should always be used.

For instance, I'm looking at the world's simplest "Hello World" class / program, and thinking that if you took SOLID seriously you'd be required to rewrite it as four classes/interfaces. (Because the two pieces of functionality -- marking the main entrance to the program and printing a message -- should be separated into two classes under SRP, and then each of those classes should have an abstract interface and a concrete implementation under DIP. Actually, I can even see an argument it should be six classes...)

That is to say, the SO/ID parts of SOLID are at war with KISS/YAGNI. And personally, I think KISS/YAGNI is the clear winner: you shouldn't be pulling in all that abstraction unless you actually need it. When you need it, abstraction is the greatest thing ever, but when you don't, it just makes your code needlessly complex.

NAMBLA interpretation: NAMBLA references are jokes, Jeffs Ultimate Whatever is a joke name, some people do not get the joke. Even though its a joke, it doesn't mean the whole post is a joke.

He *IS* the Messiah!

The difference between rules you provide and people really thinking about software design is that they aren't substantive.

It's not that it isn't bad general advice. But what is worse is that you appear to think it is a substitute for attempting to codify good practice in a reusable way.

Who cares necessarily what the bad programmers are going to do, they're going to copy other peoples code anyhow - and aren't going to be helped by you.

But regarding the harm of rules... codification of good practice happens all the time. It's obviously part of programming language development, we're not just doing loads and stores to registers and memory and doing maths operations on them.

The irony is that you sound similar to a hardcore assembler programmer 25 years ago. Don't use C you'll stop thinking about the code!

I think you'd want separation of concerns in there too and that plus DRY should give you the basics of OOP too.

As a programmer who never went to uni I started off with DRY and it gave me plenty of distance in telling me how to structure code.
SoC came later when I realised that mixing GUI and database code wasn't really working. KISS unfortunately only came to me later when working in large teams and asking myself if others would understand the code and YAGNI is for project management, timelines and your role as a developer.
The "get shit done" philosophy applies to any job really so doesn't live here.

It's interesting to pull this stuff apart, look at MVC for example, that's basically just SoC, State pattern is a bit of DRY and so on.

I agree that you can trust in DRY, KISS, YAGNI and SoC. Everything else requires a bit more cynicism to see if it is relevant and useful.

My Response:
http://dotnettricks.com/blogs/craigbowesblog/archive/2009/02/14/739.aspx

Personally I would have reversed Yagni & Nambla.

your argument is sound, but it represents a single programmer position. In most places, the programmer does not work alone and needs some supporting workplace. The workplace should support the programmer and provide him with the tools and information.
this might me the team leader or system engineer.
more can be found at:
http://design-to-last.com/index.php/Technical/software-design-rules-made-to-be-broken.html

Daniel

Some John Smith originals, not poetic: "This is my world and you are just a tourist".

Jeff, I love your blog and StackOverflow! Keep it up!

Dunno if you've seen this one or not:
http://lost-theory.org/realultimatepower/

Jeff,

I tend to be skeptical of new methodologies (though SOLID isn't exactly new) also. I think the reason is that they get overhyped, and then instead of good principles we are innundated with bastardized versions of principles that required refinement and clarification in the first place. For instance, now that Agile has taken the developer community by storm (I haven't consulted at a company in the past year that hasn't claimed to be doing some form of Agile) it is starting to sour, and all we can say is that people aren't doing it right (c.f., Fowler's "Flaccid Agile" bliki). But if so many people aren't doing it right, wasn't there something wrong, or inherently vague, about the principles in the first place?

Programming is inherently difficult, however, and I don't think assuming that the community is full of dummies (I understand this was rhetorical and you probably don't really think this) is the way to go. The intended audience of these various principles and methodologies is reasonably smart and competent people who may be stuck in shops that don't promote good programming.

The right way to evaluate SCRUM, XP, SOLID, et.al., is whether they are helpful to that kind of audience. If not, then there are problems -- that is, if they are only helpful to the 5% of genius developers out there, then they aren't useful. If they are good for the 75% of developers who are neither geniuses or dummies (me!) then we need to see what is good about them and what could be better.

Thank you for raising the issue, Jeff. Someone of stature really did need to do it. We have lots of methodologies and our code isn't necessarily getting better as a result. In some cases, it may be getting worse.

Yeah, but we still use object oriented programming.

Nope. You're still missing it. Papers and books on design patterns and software engineering principles help those who do care. It's not an overarching concern about those who don't.

Should those in the know not share because it will immediately get labeled as you've labeled the SOLID principles? Why even read all those programming books? Why did the GOF waste their time?

Your argument still rings hypocritical.

vb coders != cowboy coders

Am I the only one who is afraid of clicking a link named "NAMBLA"?

Can someone explain NAMBLA from the point of view of someone
1. not in the USA and pretty unaware of american culture
2. has never heard of NAMBLA
3. has not seen the Southpark episode
4. has no access to youtube
5. cant understand how the main google results for NAMBLA are relevant to a list of programming principles

I vote we throw a book at Jeff. Something like "Programming Windows" (Charles Petzold) should do. It's a nice heavy volume. "Solid", you might say.

For goodness' sake, man, when you make a blog post that betrays a serious ignorance and you get lambasted for it, the last thing you need to go and do is right another completely off-base post, incorporating various stupid elements ("religion", "NAMBLA") to try and put your point across in a "cute" manner.

Your "golden rules" might well work for you, but maybe, just maybe, there are real, honest-to-goodness professionals who adopt a different set of core principles, and perhaps, just perhaps, they work for them.

This lecture on "robust code" and "software quality" is, of course, coming from a guy whose web site leaves a hell of a lot to be desired, and who follows no real process for quality - not even a real bug tracker.

Is NAMBLA the reason programmers get sacked at 40 and why they're mainly male?

I've been reading this blog for a while now, and every time I finish an article I get the feeling I'm a worthless programmer.

I don't think it's because I actually am worthless (at least I hope not). I think it's the tone. It feels elitist and condescending. The subject always seems to be, "Do you adopt/know about this? If not, you're an idiot!" It's painful to read in the same way that I imagine it's painful to be shouted at by a drill sergeant.

I wouldn't be so bold as to demand or even ask for a change. I just thought I had to say my bit.

I spend my time learning new web development technologies like RIA, AJAX, and open source web applications. I don't have time to keep up with the latest programming fads being pushed by enterprisy fashionistas.

Hey Jeff, your "Atwood System of Real Ultimate Programming Power" list appears as all ones, instead of one through four, in Opera 9.63, because your generated HTML has wrapped your LI items with H1's.

1. DRY
1. KISS
1. YAGNI
1. NAMBLA

@Leif Eriksen

Google has a great Define feature:
define:NAMBLA

It stands for the North American Man/Boy Love Association.

It is a pedophile organisation. Others have pointed this out before! I can't really find a reference to explain any other meaning.

@Rob
I'm inclined to agree to an extent. For someone who has read so broadly, the development mistakes are staggeringly basic - like the SQL "deadlock" mistake a few months back. A rookie DBA would have known his thought process was flawed.

So - what does this tell us? Even someone who promotes professionalism in programming will not implement professionalism in programming?

Actually - I don't think that is the full story. I think Jeff actually does a stand up job in development and in the development community. I just think that there might be a lack of objective introspection. That is - how can we rate ourselves when we are never independent?

It is my opinion that, reading every book ever written will help us to become better programers, but to be great programmers we must receive independed objective feedback from our peers (i.e. not management and not customers).

This is only a theory as I have never seen this implemented.

It's nice to see other people coming around to the fact that most of Jeff's posts are simply noise generators; his dogmatic statements don't do much for me, but at the very best his posts are good for starting conversations, both in the virtual world and the real one.

The divisive "us" and "them" mentality attracts a lot of people, but at the end of the day causes more problems than it is worth. I prefer Scott Hanselman's measured, humble approach to things, he doesn't make people feel stupid.

Stack Overflow is actually useful though.

Philip, I agree with what you are saying and it is interesting because a few people (including myself) mentioned the paper titled "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" in one of Jeff's posts from last year: http://www.codinghorror.com/blog/archives/001160.html

Maybe Jeff would do well to read it, I know it humbled me quite a bit.

I've come up with the latest programming paradigm! yay!.

FDD , or Fanboy Driven Development.

You get the latest idea or fad in programming , and stuff it down the throat of everyone who's around you , to the extent that you proclaim that any previous code written must be garbage because it doesn't use your throat-stuffing idea.

@philip

thanx - I still really dont understand why its in the list.

some seem to indicate its a joke, in which case I dont get it.

maybe i'll just reference the first 3 - nothing new there.

@Leif Eriksen

My assumption is that it actually means something else - but since I can't get You Tube at the moment - I can't confirm that....

Jeff, you nailed this one down so good, people are gonna scream your name for generations to come, and point to your blog when someone will try to sell them principles ever again ... and the other 80%, well they still won't know neither side of the story ...

I can fell the hurt and the damage your produced out there ...

Good job, I felt this way all along ...

It'll never catch on, ASRUPP is not a catchy acronym. I wonder how often the acronym comes first. I mean 'SOLID' principles to create solid code - what are the chances of that ;-)

My name is Dave and I can't stop thinking about programming.

Because it's a highly creative process and inspiration can come from anywhere at anytime.

I'm terribly suspicious of some of the dates presented for real paradigms (that is, NOT Agile/Scrum/XP/whatever nonsense). Structured programming is older than 1969, even if it was not expressed as a concept until around then, and object oriented programming is FAR older than 1990; indeed, there has been nothing of particular interest new in object oriented programming SINCE 1990.

Just a quick comment on YAGNI.

YAGNI assumes you are only writing code for yourself. YAGNI is a principle that only applies to one-man-companies or very small companies, where I can simply type into a chat "Hey Paul, could you please implement a function to do XYZ" and he'll reply "Sure, will be done it two hours".

Everything a little bigger than that will fail horribly if you program according to YAGNI. I'm writing a lot of libraries other people will use. I may not need a certain function, but I would be a moron to assume just because I don't need it nobody else will. As a library developer I have to foresee what OTHER people will need. And since that is impossible (I'm no fortuneteller), I must implement everything any developer *might* need one day. I have a time schedule, I cannot leave half of the functions out and just implement them if someone asks me for that, I must implement it when my time schedule says "Work on that library" and everything that is not there won't be there, regardless if someone needs it. That's how it works once you have 10+ developers in a company.

You could at least have signalled that the nambla link is nsfw. I thought I could trust the links on this site. In future I'm going to have to hover over each one and check the URL - just like on some cheesy el cheapo waste of time blog.

2002 Enterprise Unified Process
2003 Rational Unified Process
2004 Constructionist Design Methodology
2005 Agile Unified Process

Too much churn, it takes time to learn something and more time to master. Your better off using a process well rather than the lastest badly!

Console: "To me the basic point here is that there are no silver bullets."

It always amazes me how many people just say that "there are no silver bullets", indirectly indicating that nothing can make things better.

What "No Silver Bullet" really asserts is that "no single software engineering development will produce an order-of-magnitude improvement in programming productivity within ten years" (quoted from "No Silver Bullet" Refired). It also says that a tenfold improvement is possible incrementally through many efforts.

Nobody is claiming that SOLID, TDD etc. would produce an order-of-magnitude (10x) improvement. But if it would produce 2x, 1.5x, or even 1.1x improvement in productivity or quality, do you not think that it would be worth the effort to learn how to do it? They might very well be part of those incremental efforts that Brooks advocates in "No Silver Bullet".

@Jeff
"the types of programmers who would most benefit from these guidelines, rules, principles, and checklists are the least likely to read and follow them"

Seems a pretty big assumption to make. Inexperienced programmers would benefit from them, for example. There are certainly developers out there who are quite resistant to improvement, but that doesn't mean these guidelines are irrelevant.

Are you suggesting that good ways to program not be documented? Not everyone will be in a position to be mentored well, and things like this are a way of promulgating the collective wisdom of better developers.

How did you get better at programming? By being directly taught, or by reading things like this and thinking about them?

It seems kind of obvious to me that you have read about these things, so I don't see why you think no-one else should.

Also, you have at least one of those dates wrong. RUP dates from the 90s sometime, as the Kruchten book dates from then

http://www.amazon.com/Rational-Unified-Process-Philippe-Kruchten/dp/3827315433/ref=sr_1_5?ie=UTF8&s=books&qid=1234786008&sr=8-5

Also, object oriented programming dates from at least 1967

@dan
It's a link to a Youtube video of the Daily Show, not horse porn. And besides, do you normally blindly open every link you see?

Maybe the W3C should remove the <a> tag from the next version of the HTML spec, heaven forbid someone might get offended about something on the internet.

And Scrum is from no later than 1995

I assume that the point of the NAMBLA joke is to hint that this whole post is a joke.

When you reduce common sense statements to simple-minded slogans, the true intent gets lost, and you lose sight of why they matter, and when they should be avoided. All of the fundamental abbreviations are as dangerous as NAMBLA if you don't understand what they actually mean.

At least I'm guessing that's Jeff's point. To be honest I'm finding it increasingly difficult to follow any of these recent posts, and wish he'd actually stop throwing in all these meaningless metaphores, and just explain what the problem with SOLID is.

Anybody care to explain what is NAMBLA and what is the hype about it to non-Americans?

you should have put an NSFW warning for your non-American readers.

So the sad fact is based on my experience the craziest "cowboy" developers are the Agile ones. They like to talk down to clients and other developers that don't go along with their ideas of vagueness and misleading discussions/meetings.

LMAO as I read this in the AUP Philosophies on Wikipedia:
1. Your staff knows what they're doing. People are not going to read detailed process documentation, but they will want some high-level guidance and/or training from time to time. The AUP product provides links to many of the details, if you are interested, but doesn't force them upon you.

Interested? I was once told by an Agile developer, "I don't need to read that, I know what they want!" - Well after they got off the project, I had the privilege of re-writing all of their code to actually do what the client requested. Don't you love progress?

I've read this blog for years, and I care about the code I produce. However, we still whip out cowboy code in a pure chaos environment. It's not something I can control!

When your management and customers 'just want it now, and f%*k the spec', when they don't understand what you do and don't want to, then it is very difficult to do anything else. And they all care about Agile/Waterfall/RUP/RAD/JAD/acronym-of-choice, but only so long as they don't have to learn about it. Hence, even when you do have some design patterns, they can be poorly understood and implemented.

The ones you call unreachable are the ones who are constantly tasked to do miracles in short timeframes. They juggle dozens of projects at any point in time, and fundamentals are the last thing on their mind, and the last thing that their management cares about.

Your inclusion of a disgusting reference to NAMBLA - even in jest - says a lot about yourself.

I agree - what a sick, sick joke - Jeff you should be ashamed of yourself

It is really quite amazing to see the number of comments that pick apart all Jeff's articles, misinterpret it in some way and then argue strongly against that misinterpretation.

I would say that Jeff's goal is to create an entertaining blog that tries to gently push software developers in the right direction. He is not writing the holy doctrine of software development.

Also, sometimes he posts about certain topics before he has mastered them completely. This provides unique insight into the learning process that all software developers are constantly undergoing.

So anyway, thanks Jeff. I enjoy your blog and find it both useful and entertaining (even if I don't always agree with you).

NAMBLA. wow.

Hey Jeff, don't miss the "97 things every architect should know" (Oreilly).

You should also check out the Get'er-done methodology. Too much process indicates you are "managing" automatons.

Scrum master sounds very cool.

How about SCRUBLA, Jeff? New methodology focusing on, erm, scrubbing. Sort of like screen scraping, but for koderz.

I was hoping for some ninja moves.

The number of "modern" programming systems and concepts have now expanded beyond the time or ability of any single programmer's ability to master.

And to what end are all these wonderful new names for distinctly not-new ideas? My Windows machine is arguably no faster and no more or less troublesome than my old DOS 6 machine. We've replaced unscheduled crashes that require a time-wasting reboot with scheduled security updates that require a time-wasting reboot, followed by an inane suggestion that I review the updates. (Gosh, yes, I'm so excited about the latest Windows updates I'm about ready to s**t my *knickers!* Aren't you?).

My Ubuntu machine is little better. The device driver recognition that was solved with Windows is so poor that I can't see any USB or even print using an LPT1 port without major machinations.

So what, exactly, have we bought with object oriented programming, agile development techniques, et. al? My day-to-day application experience hasn't changed much at all. I've got video and sound on the computer now. Yay. And I can handle bigger files in memory. Yay. Oh, and I have a cartoon colored point-and-click shell. Yay.

And so what? I think my best trade-off point was Windows 2000. Nothing much has improved since.

Are you people not aware that this blog's purpose is simply to get your comments, boost page views, self-linking, etc?

This blog is for marketing Jeff.

@Michael

I have to say you are dead on. I won't go into it much further, but I appreciate your post on the subject. Oftentimes the best approach is a little more balanced.

@Greg:

"It is really quite amazing to see the number of comments that pick apart all Jeff's articles, misinterpret it in some way and then argue strongly against that misinterpretation.

... Jeff's goal is to create an entertaining blog ... He is not writing the holy doctrine of software development.

So anyway, thanks Jeff. I enjoy your blog and find it both useful and entertaining (even if I don't always agree with you)."

Here, here! Yeah, what he said! I second the motion!

@ThatGuyInTheBack:

"I think my best trade-off point was Windows 2000. Nothing much has improved since."

For me, it was the PDP-8. With no peripherals. Only front panel switches.

(OK, just kidding. At least there were no holy programming writs back then to make a programmer feel guilty for blasphemous ignorance.)

Wrote a reply on my blog here:
http://nothingyoumissed.wordpress.com/2009/02/16/caveman-marketing-jeff-atwood-and-solid/

To keep it short, I (mostly) disagree.

Jeff,

Your "argument" about being unreachable is a bit over the top: you either can or cannot stand on your feet as as programmer, architect or whatever you call yourself. Those who can will find information and resources that will give them the edge in the marketplace.

Those who don't will continue their feeble existence. Nobody, including you and your blog will change that. You can throw a digital library on their head and it would not help.

Your blog has become the Enquirer of the technical blogs. I read it for the scandal and gossip.

There's one thing you can do trying to keep up with progress or code like you always did. If you started in maybe Fortran, Basic, VB, ASP or maybe PHP - you continue to script your code in good old plain procedural programming. Too much OO slows you down...
New shiny thing,,, i don't give a damn - I code it like I used to, get the machine obey my will, not the other way around...
And you don't get more paid if you code spaghetti or nice code when your boss asks for results, time is money!!!
Ideals are good in a perfect world - I could say the search for programming utopia or something...

@Wanko -

Yes, there is no perfect solution or code base. And you'll be surprised to learn that there can be quite a pay difference between code coders and spaghetti coders or those who can design something flexible and those who can't. Try getting through an interview where I work. You won't.

It's about being a professional and personal responsibility. The best in any profession do this. Jeff does this too - don't misinterpret. Spaghetti is crap. No one here encourages crap.

The plural of Jeremy is NOT Jeremies.

Wow!

Agile/TDD/SOLID people think they are better than others. When someone posts on their blog an article that says their *NOT* adapting the "hype" then, guess what? You see BS comments all over. When these zealots posts on their blog on how a certain methodology changed they way they code then no one complains. Why?

It certainly is amusing to read the comments here. A "phenomenon" that can be seen in other blogs as well.

>Throwing a book of rules at a terrible programmer just creates a terrible programmer with a bruise on their head where the book bounced off.

So, I'm, uh, skeptical that throwing a copy of Strunk & White at someone who's a terrible writer is somehow going to work better than this. Yet when I say that, I get all kinds of grief from the True Believers who think that placing a copy of that tome carefully on the shelf will turn a typist who produces vacuous, flabby, pedantic, jargon-filled text into a Good Writer.

Does not compute.

The most interesting part of this debate, I think, is stackoverflow.com, though it hasn't been mentioned much. Jeff and Joel have already put their money where their mouth is in backing an idea on how to better the state of programming in the industry. Unlike a lot of the pie in the sky fantasy systems out there (TDD, SCRUM, SOLID) which are boring, bureaucratic, process heavy, and easily misused their solution is fun, has a low cost of entry (virtually none), is immensely practical to programmers at every skill level, and is virally infectious. Not to mention that it is flexible to the needs and state of the industry.

Stack Overflow is only a few months old and already it contains many a substantial critical mass of collected wisdom from across the breadth and depth of the software industry. Ultimately I think the full impact of stackoverflow.com in advancing the state of the industry will be very substantial and will vastly exceed many of the fad processes, checklists, and rulesets of today.

On the matter of KISS, I am thinking that might be a good compromise between bureaucracy and nothing at all.

**Stack Overflow is only a few months old and already it contains many
**a substantial critical mass of collected wisdom from across the
**breadth and depth of the software industry. Ultimately I think the
**full impact of stackoverflow.com in advancing the state of the
**industry will be very substantial and will vastly exceed many of the
**fad processes, checklists, and rulesets of today.

There is nothing in common between answers to specific programming problems and general guidelines, wich are a way to abstract vast knowledge accumulated by experimented programmers

Your fanboyism is not inspired :P

**Your blog has become the Enquirer of the technical blogs. I read it for the scandal and gossip.

I agree with this so much, there is a certain taste toward bold and uninspired statements lately ..

@Raph, you don't get it.

Consider apprenticeship, what are the key elements of apprenticeship? How does an apprentice acquire the specific and general skills of a craftsman? Well, the master craftsman will demonstrate work for them so that they may follow the example; the master craftsman will guide their work by correcting their mistakes and giving feedback on their work; and the apprentice will spend years doing actual, real work with the master craftsman available to help with the harder parts. Furthermore, constant practice will reinforce certain themes from the many instances of specific guidance from the master craftsman which are part of a broader context of quality craftsmanship. And, of course, ongoing discussion between the apprentice and the master craftsman will further develop general ethics and guidelines of work.

All of these elements exist on Stack Overflow. Stack Overflow is a communication channel which connects experienced developers with less experienced developers. It's not nearly so worthwhile as an actual apprenticeship but providing even a fraction of the world's less-experienced developers with even a fraction of the value of an apprenticeship adds up, in total, to a honking huge effect on the software industry as a whole. Stack Overflow is like pair programming with the entire software development industry.

It's easy to underestimate Stack Overflow, after all it's just a QA site. But if you spend some time thinking about it seriously and imagining the cumulative impact that it's had and that it will have, it's rather astounding.

It's all the more remarkable when you consider that rather than being force fed this stuff people are eagerly consuming it. People ask a question from some problem that requires immediate attention at work and they not only get an answer, they get a little bit of insight into how other programmers work, and they also, sometimes, get tiny little morsels of wisdom from more experienced folks. Perhaps they even get told that they're going about things entirely the wrong way and are given examples of better ways to do things. These are small things in isolation, but they each have an impact, and they are many.

One could do far worse as a means to acquiring an education in software engineering than to do nothing other than visit stackoverflow.com and read through the various questions and their answers under the "best-practices" tag:

http://tinyurl.com/cps9ld

In response to Stephen R,
I've had allt these high beliefs in object oriented design and all sorts of things, but when I got a job and the system they have is all spaghetti and they're making good money and no one complains. The customer can't see the code you wrote. So is it worth it? Maybe..
The post was meant to be ironic, which you somehow didn't figured out...Maybe you can figure out how to solve todays coding problems(or maybe you have you're head all uptight with all sorts of abastact ideas with little immediate practical value)..

Deliberate irony or not I think the argument in this post undermines the previous one. The post on Ferengi Programming was arguing that you should not use principles and processes too rigidly, but let programmers think critically about there work.

But in this blog the argument is that 80% of programmers are too stupid or lazy to ever understand decent principles. But if that is anywhere near the case, surely that would mean you do have to start enforcing these principles rigidly, and have a good process to ensure they are applied correctly. Otherwise the 80% of your workforce will be drowning out the “elite” programmers with their dreadful code.

As I understand it, the original complaint about the SOLID principles was that they were written by someone who had no real-world experience. That getting things done in the real world was more important than code quality.

I’m beginning to wonder if the same charge couldn’t be made about Jeff’s posts. As far as I can see his only experience of product management is StackOverflow, which only has a handful of developers, all of them “elite”. It also has no real customers, or deadlines to meet, and being a website can easily have bugs fixed after release.

But in the real world there can be projects with hundreds or thousands of developers, and the cost of missing a deadline might be millions. In such environments there just isn’t the luxury of making it up as you go along, or reinventing the wheel just for the learning experience. You have to have some sort of process, some principles, to have even the slightest chance of not having the project fall into a blackhole.

Rules are for the fools and guides are for the wise.

@anon

>It's a link to a Youtube video of the Daily Show, not horse porn.

Youtube is blacklisted here. So I googled it. Not a happy result.

>And besides, do you normally blindly open every link you see?

On silly websites no. On what I thought was a sensible work related site I don't always take the extra 2 secs to hover, wait for url to appear, read url. After clicking on 3 previous sensible links I didn't think to bother url checking the 4th. But now I know coding horror is into rick rolling I will check in future. Or maybe just read it less.

Wedge wrote:
> http://tinyurl.com/cps9ld

Oh yeah like you're going to get anyone clicking on that. We can't even see the url to find out what kind of dodgy activities it may be linking to.

Any list of essential developer acronyms is incomplete if it does not contain RTFM.

@dan

Well then you can't go on complaining about how *this* site is sending you to all sorts of lurid places, because you did that search entirely out of your own volition. (And what kind of browser takes *two seconds* to display a url in the statusbar?)

Also, if you're so scared of everything, set up tinyurl to do previews. http://tinyurl.com/preview.php?enable=1

Your sort of whining is nearly as bad as those Christian groups that claim to be offended by the fact that Penthouse contains nudity.

Atwood has jumped the shark.

+1 for RTFM

I try not to comment this late, but I just saw a TED video that made me think of this discussion.

http://www.ted.com/talks/barry_schwartz_on_our_loss_of_wisdom.html

"A Wise Person Knows: When and how to make the 'exception to every rule'" (at 3:50 in the video)

(this one is slightly modified to re-focus the idea toward programming)
"as we turn increasingly to rules, rules... may make things better in the short run but they create a downward spiral that makes them worse in the long run. [Skill] is chipped away by an over-reliance on rules that deprives us of the opportunity to improvise and learn from our improvisations." (at 8:40 in the video)

--
Also, I like Dhananjay's exercise analogy, because I like to check out different exercise routines and talk to other people about stuff they do. Then, I incorporate those ideas into my own workout. (I don't just take a pre-written list of exercises and perform them)

This is exactly what Jeff talks about doing with programming. To me, that's the point of this post.

and yes, I do realize Dhananjay was arguing *against* Jeff's position. I found his analogy useful, anyway :)

jeff, you suck!

Exercise may be a bad analogy because you get immediate feedback from your body. If you're doing something wrong, it hurts, and in a bad way. If you're doing something right, it hurts, but generally you can tell that it's hurting in a good way.

With programming, how do you know that it hurts? How do you know if it's a "good" kind of hurt or a "bad" kind?

A few quotes that I thought were insightful:

cc - "Though, having so many principles to follow has some draw back. Some people just don't try to understand them well before using them."

wedge - "It's not nearly so worthwhile as an actual apprenticeship" (referencing StackOverflow.com)

Steve W - "As I understand it, the original complaint about the SOLID principles was that they were written by someone who had no real-world experience. That getting things done in the real world was more important than code quality."

Jeff Atwood "Remind me again -- who, exactly, are we writing these principles, rules, guidelines, and methodologies for?"

I would like to answer that question, but first a short story:

I feel like my first 12 years of my career was wasted.

I was a talented programmer. I could solve every single problem thrown at me in a fairly efficient and intelligent manner. The code that I wrote worked. I had read nearly every book I could get my grubby little hands on, yet still I was missing something.

Finally, 12 years into my software development career, I met someone capable of mentoring me.

Looking back I can truthfully say that most of the code I had written before that sucked, even though my managers and co-workers thought I was a programming demi-god.

Before and after my "apprenticeship" I can tell a difference. My mentor can tell the difference. There is a hugely astounding difference.

Now, re-reading many of the books that I had read prior to my "apprenticeship" I can fully understand them and apply them... but that's because I've already experienced the problems these books are trying to solve and I had someone to help show me the correct principle, design pattern, etc to apply for any given problem.

A knowledgeable person reading correct principals and guidelines can recognize them as correct and apply them correctly.

A less experienced person will generally reject them as "written by someone who had no real-world experience" if he even understands what the author was trying to say in the first place.

To answer Jeff's question: We're writing these principals as a way of verbalizing and fine-tuning that which the masters and mentors already understand. They're not in and of themselves capable of teaching anything. They're to be used as a bible, dictionary, glossary and reference manual, not as a teaching textbook.

For those that have not yet mastered their trade, the best we can do is to mentor them. Let them make their mistakes and then kindly, gently, show them the better way of doing things.

I've been on the giving and the receiving side of such a relationship and I have to say there is no other way. There is no "golden solution"... or at least none that I've found so far.

Nice article!

Jeff,

I like your blog for the most part and think it's been fun. It's great you've been able to turn your blogging into a great startup. Good work there.

But I've removed Coding Horror from my RSS reader. My basic problem is that you seem to have nothing new to add yet continue to write once a week. Since you don't have new content, you end up saying the same things over and over in more inflammatory ways. I agree with this post, for instance, but I want to argue with you about it because of the aggressive way you assert your point. (In essence, I feel you fail to adhere to DRY. ;-)

I don't mind trying different ways to make your points entertaining and so on, but I do mind having my time wasted. By necessity a regurgitation needs to look different in order to be entertaining. That's why flashback episodes of sitcoms always have a bit of new material to set the show up. But at the end, when you see how little new stuff was in the show, you still feel cheated.

Basically, this blog has become a time sink for me and I need to cut it out of my life. (It's not you it's me and all that.)

Sorry, Jeff, but I've pretty much lost any professional respect I have for you. You are a hack who doesn't know he is a hack. You are yet another guy, who calls himself a programmer, that refuses to listen to good advice and is determined to blaze your own trail and ignore the wisdom of those that have gone before you. I've spent years working with people like you who keep making the same mistakes over and over and pontificate about solutions. All the while ignoring the evidence surrounding you. You mock cowboy coders, but failed to realize that it exactly what you are. You fool yourself into thinking you are a professional because you don't use VB and read a few blogs.

You are a hack. And irrelevant.

unsubscribed.

If we look at just a few items from this list...

1969 - Structured Programming

Are you writing applications in C, C++, Java, C#, Pascal, Ruby, Perl, Fortran 78, or ...? Oh, guess what? You're benefiting from structured programming.

Do you even know what structured programming was? Structured programming was the revolutionary notion that you can code strictly by combining statements like if...then...else, do while ..., begin...end or { ... } in small functions to create readable maintainable code. This was controversial and revolutionary in the industry in the '70s; I was new then, and I remember the arguments over it. If you think tit was superfluous, perhaps you should try restricting yourself to writing a few monolithic applications in assembler and Fortran IV. Maintaining MLOC applications became feasible thanks to the widespread adoption of structured programming throughout the industry and its incorporation into all the languages which have become standards.

1975 - Jackson Structured Design

Still timely; besides pushing for the use of structured programming constructs, Jackson introduced the idea of a structured way to backtrack or handle failure in your code, via posit...quit. This ultimately evolved into modern exception handling structures. If you ever write try { ... } catch( ... ) {...} finally { ... } you're building on his work.

1990 - Object-oriented design

(BTW, Work on Smalltalk began in 1969, and was publicly released in 1980 so you're off by about a decade here.)

Of course, object-orientation is a passing fad. Uh... you're not by any chance writing in C# are you? Oh good. Hope you're not using Java, C++, Ruby, Delphi/Object Pascal, Objective C, etc. either.

If you've used object-oriented languages for a while, you have probably absorbed some of the once controversial object-oriented design principles to where they seem second nature. Like structured programming, once you've soaked in them for a while, they seem trivial and obvious, but they weren't 20-30 years ago.

Lumping these major advances in the industry together with relatively short-lived design methodologies is pointless for anything but trying to score cheap rhetorical tricks.

"tit" -> "that it". Sigh.

"You fool yourself into thinking you are a professional because you don't use VB and read a few blogs."

It's hard to take you seriously when you haven't even read enough of Jeff's stuff to know that he is a proud VB programmer.

If Jeremy (the teamlead) is not into reading the latest must-reads on software development than Jeremy is simply NOT THE RIGHT MAN FOR THE JOB.

The real decisionmakers of the company should know who to give the role of teamleads..

Methodologies are for managers [grin].

Although it's good that someone thinks about and formulates these principles, for the benefit of those who can appreciate them and maybe apply them, they are not meant for the "masses".

The reality is that, in general, 20% of the programmers in a team produce 80% of the work. This is not always true, but it's a frequent situation, because a lot of job interviewers are, um, tolerant.

What I mean is: The teamlead should at least be a person to get the team up to a certain acceptable level.

http://www.mellekoning.nl/index.php?entry=entry090107-162144

>Your sort of whining is nearly as bad as those Christian groups that claim to be offended by the fact that Penthouse contains nudity.

Yeah it's terrible that the white house contains nudity.

I believe in ONE rule/process/methodology:

1) Hire good people.

If pressed very hard, I will also admit to being very fond of encapsulation.

@Clifton:

I'm not disagreeing with your comments, but would like to expand on them a bit. And *MAYBE* lower the heat a bit.

Like you, I experienced the structured debate first hand in the 70's, and the new ideas since, like object orientation. Before languages came along that supported those ideas with built-in constructs, they had to gestate in an environment of more primitive, but popular, languages. To apply those ideas meant manually, mentally, forcing them into more primitive code.

For example, I started structured programming in unstructured Fortran, COBOL, BASIC, and various assembly languages. How did I do that? By adopting fill-in-the-blank patterns of ifs, gotos, and labels (templates, of a sort) that simulated do while, case, etc. Lacking good editors, cut & paste, macro facilities, etc., it required typing in those patterns, filling in the blanks, every single time. That took time and mental effort. The benefit to me was the clarity afforded by structuring, but that was lost on others who hadn't grasped the ideas yet. And they weren't interested in learning, because it meant more work, and there are always more pressing priorities.

In the 80's, I experimented with doing OOP in C, using similar conventions, patterns, and mental gymnastics. There was some value to it, but it did add work, and was not appreciated by others who found it weird.

The real advances came, not when the ideas were born, but when mainstream languages became widely available that supported them directly. Those higher-level, more abstract, ideas then became easy and natural (and the debates went away).

I think one aspect of the debate about SOLID and other formalized principles is that they add work (mental, training, or otherwise); an uncooperative C++ must have the ideas hammered onto it manually and deliberately.

Languages and tools down the road will likely support many of those principles directly (some may already, but I don't want to get tangent debates started). When that happens, it will all be easy and natural, and the debate will go away.

So, both bashers and cheerleaders of SOLID have valid points of view. Bashers are looking at the here and now, the costs and practical difficulties that get in the way of using better, but more abstract, ideas. Cheerleaders are striving for a more idealized situation that doesn't exist yet, and won't, until the tools catch up and lower the level of abstraction to that of convenient, built-in, and invisibly supported, so that Jeff's bruising "book of rules" is no longer needed.

In the meantime, bashers focus on getting deliverables out the door using the resources and people at hand, while the cheerleaders blaze better trails.

>>In the meantime, bashers focus on getting deliverables out the door using the resources and people at hand, while the cheerleaders blaze better trails.

The part you are missing is that the cheerleaders are saying the same thing. Following a few basic guidelines won't make your project take longer AND it will be more maintainable. Sort of a win/win.

The part that has confused me over the past two blog posts is the assumption by some peopole that following basic guidelines (or principles, or whatever we feel like calling them) is somehow difficult, when clearly it is not.

I think there's value in reading what someone's ideal design principles are, but one of the best things about being a human is our ability to act in a manner that best fits a situation without tying ourselves directly to rules and principles. Any time we say "YOU MUST DO THINGS THIS WAY," sure, it imposes some structure, but it also limits our ability to try new things that may solve our problems in a new and superior way.

One final ironic aspect to this. The link in this article to DRY actually points to an article on “Curley’s Law”. (So rules are a bad thing, but laws are fine?)

Here we find one of the main points of Curly’s Law is,

“Although Curly's Law definitely applies to normalization and removing redundancies, Do One Thing is more nuanced than the various restatements of Do Each Thing Once outlined above. It runs deeper. Bob Martin refers to it as The Single Responsibility Principle:“

As this is the same principle that Jeff and Joel seemed to have the most problems with in the StackOverflow podcasts, I’m now officially confused, and am just going to assume this whole affair is just a massive troll.

Apologies for the previous comment. I've just checked the transcript of the podcast and realised that Jeff does admit to having linked to the Single Responsibility principle.

I'm still confused as to how you can get from DRY to SRP.

Seriously? You can't understand why these principles/fads are developed, written, and codified into frightening management nightmares?
It's easy.
Management wants it. Programmers want it. The ones reading them aren't the ones expected to adopt the rules, they're the ones expected to PROPAGATE the rules, in an effort to make those worse than them better in some measureable way.

As to the source of a lot of this: new design principles are necessary to improve the average quality of code worldwide. Hence object oriented design. They will, and should, continue to be created and evolved.
The danger comes from the "285 Rules of Acquisition", to stick to Jeff's terminology. Object oriented design is fundamentally simple to explain and describe, even in great detail. But when given a large textbook on the subject, with hundreds of so-called "rules" that have nothing to do with OO except what's in the author's prejudiced experience, it can easily cause more harm than good. It certainly turns intelligent people away from programming (I've seen it happen many times).

Jeff has finally passed the plateau of a technical blogger and became an entertainer :)

"Best Practices" and "Methodologies" are, just like the parties, designed for those who are not invited (read: can't program no matter what you do to them :)

I suggest you bring this stuff to Youtube.

I think the point of NAMBLA in the list is to draw attention to the fact that people stop processing what you're saying when you start using acronyms.

One of these things doesn't belong:

1. DRY = Don't Repeat Yourself.
2. KISS = Keep It Simple Stupid.
3. YAGNI = You Aren't Going To Need It.
4. NAMBLA = North American Man/Boy Love Association.

I'm clear on what 1, 2, and 3 mean. I'm completely at a loss as to what you mean by including NAMBLA. Can I offer some possible explanations, and can you tell me which one is correct or at least close to being correct?

a. Jeff is a member of this group and has found that it increases his programming wisdom.

b. All other acronyms for other programming methodologies can be substituted with NAMBLA because those methodologies advocate homosexuality between men and boys.

c. Jeff is trying to lure his readers into a recursive and pointless discussion as to the meaning of NAMBLA as it relates to programming methodologies. His only purpose in this is to get a laugh out of all of the posts questioning the NAMBLA reference.

Jeff, am I at all close on any of these? Can you please help me connect the dots on your reference to this?

@Dave:

And at that, I declare this thread dead (as far as I'm concerned.)

(Attention, Jeff Atwood: It would be a really fine idea to let us in on what the joke is supposed to be.)

What troubles me about most of this discussion is that the authors all have no doubt they are experts. When I see this I always worry about the central conclusion of the paper Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments. In summary it says, if you are no good at at an intellectual task you are likely to think you are better than average. If you are very good you are likely to underestimate your competence.

That was not a good joke to pull, the world doesn't need jokes about pedophilia.

I'm just glad I knew what that acronym meant and didn't click on it.

It woould be great to have time to read all the texts and keep up with them all. But there really are only a few fundamentals.

I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

Alanna

http://www.craigslisthelper.info

que bestera

This sounds very much like chess openings.

You have a million books and terms that you can throw at people and dazzle them. For instance, "to counter that knights offense, just use the black's sicillian defense" could easily relate to "on this project I would only use DDD with an Agile Scrum master". In the end these are just terms and words that have little to no meaning if even one person on your team does not understand them fully.

In the end it is all about being able to get the work done before the deadline with as few of bugs as possible. Like chess openings, it is important to know the fundamentals behind the opening. With these patterns it is important to know when to use them, what they are and what the cost is to apply them to your project.

Would you really use the four you listed on every single project that you do?

I personally feel that people should move away from these terms and get back to the core fundamentals. Gather requirements, design, storyboard, implement, test and rinse and repeat. It really does work.

Thanks, Jeff. I needed that. You really helped me snap out of it. In fact, just last night at 02:00 I had the Design Patterns book cracked and I was looking for just that right right pattern when I already had a working class with shared factory methods. No need for a singleton, no need for an abstract factory, YAGNI.

Again, thanks. :)

really good to know this, thanks for sharing.

I love links of london jewelry.More surprise! More fascination.The most elegant links are on show, Which will enhance your taste of fashion.
linksoflondon

It make me crazy.

Thanks for your useful info, I think it’s a good topic.

Wow, you should look at how this post is formatted on your feed, especially at the end. Looks wacky.

Sorry, but seems like another non quality post on otherwise very good blog.

An elderly gentleman being, one evening, in the company of some persons
who were much amused at the witty sayings of a child , said to some one near him, that witty children usually made stupid men. The child heard him and said to him: "Sir, you were very witty, no doubt when you were young."