CodeClimber

Simone thank you for putting this together. I saw some of the articles you mentioned but not all of them -- seeing them in context really helped clarify the conversation.

When I first heard Joel and Jeff's take on SOLID I was slightly mortified because a lot of people in the development community look up to them -- even the ones that are not so passionate about programming. Taking the 'anything goes as long as it works' approach has been hurting our field for years and to many they just condoned it.

I think the guidelines are there for good reason and like you said they shouldn't be followed dogmatically.

Great point about internalizing rules. Jeff makes a big mistake by claiming he doesn't need any rules internalized or not, any experienced craftsman works using implicit rules and principles without even thinking about them. It still pays to be be able to reason about them. That's the only way you learn.

But I think you're missing an even deeper problem with Jeff's post. Principles arent rules. On the contrary. While applying rules makes for a very inflexible, bureaucratic way of working, applying principles usually takes thought and is far more flexible. Principles are more general and describe forces in your process that need to be balanced instead of the process itself. Principles can contradict each other and still remain valid.

I agree with your opinion. This episode made me think about how I approached the design theme.
First there was the Desing Patterns, when I heard about that I bought THE book, read it and begin to put every pattern I could remember in my code. Every small project should contain at least some patterns to be considered well designed by me.
Then cames the time to re-think about this practice and I begun to use the patterns in a more balanced way.
Today I use patterns but I don't mind about it, they came naturally during the day-by-day development, they fit where they needed.
The same is for the SOLID principles, every good developer should know them but nobody should be obsessed to use them at every cost. They should came naturally.

I think that UncleBob do a great job in formalizing and spreading them.

You know what actually curbed the crappy building industry in (I think it was) early Egypt? It might have been Rome - I honestly can't remember - anyway the pharoah/emperor made a rule that said if a builder built something and the house fell and killed anyone, the builder would die. If it killed the son or daughter of a family, the builder's son or daughter would also die.

That put an end to bad buildings right quick!

I'm agree with you and I would like to suggest the Rob's solution. What how you can change it, that's the point.

>>>The problem with our industry is that bugs in software don't kill anyone. At most they make someone loose some money, but nothing more

Well to be honest - most of the time building flaws don't kill people either. In the extreme it happens - but same can be said for computer flaws (airplane crash, etc).

If we're not comparing life and limb - bugs in software cost your client far more money than the average home repair in terms of lost time, opportunity, and rewrites. Our industry burns more money than any other I know of because of lack of quality and shifting platforms.

Customers adapt to what's possible. In other words (pie in the sky coming) when our industry gets to a point where we can standardize, quality will become quantifiable (moreso than now) and clients will wait for whatever it is because they'll know what they're getting.

That's a long way off - way long way off. But it's coming.

I completely agree that these are basic concepts, but I think some people have just never had them explained in a way that they can understand. So to them these concepts seem very foreign and complex. I mean honestly the Open/Close principle at first glance isn't very obvious what they are trying to get across.

And yes, we are like house builders in the time of the Egyptians in that we are still trying to figure out what works and what doesn't. I think people just take this as "everyone is wrong, so I can do whatever I want."

Excellent post, I think we really need to try and get the word out in a more accessible way.

To answer your comment "I wonder how they develop software for medical appliances or for aircraft." - They hand check every single line of code. There was a very good article on this a few years ago by the designers of the Joint Strike Fighter. This has also been mentioned a few times in interviews with engineers at NASA.

Here are my questions:
1) How do you write test code, if you can't trust the code you write to be correct?
2) How do write test code for your UI (GUI or CLI)?
3) Does SOLID include User Certification Testing of the product?
4) Does SOLID include anything about actually validating that you understand the problem you are trying to solve?

Always remember, if someone wasn't willing to break the rules all the Agile people would still be using Waterfall.

I've waited years for people to come to this conclusion - well said my friend :)

The time comes when you have to stop buying new tools and build something with the ones you have - that's when you really start to understand all the things you've read, when you actually put them into practice and see which ones work down in the trenches.

There is one core principle that works in any develpment arena - common sense, it may not have a fancy acronym but it still has a place in the development process.

I guess there is an important difference between your average coder and the ancient egyptians: the coder doesn't get his head cut off in case the software sucks.
Another important difference is while the pharaon wanted to build the greatest monuments, today's coders are often hired to make software that is cheap and sucks on purpose.

@Kevin: agree. I think it's a pretty safe way to go doing what's proven good. However instead of "Learn the Basics" I would rather say "Know the principals and use them _when needed_".

If you apply something without knowing why you should apply it and what does it do exactingly up to the last detail then, that's bad, maybe not for what your are doing most of the time ...but it is bad for you ... I think that's what Jeff and Joel have struggled to say. No matter how good some principles are, or if they apply 99.9% percent of the time, if you don't know the tiny 0.01% percent when that doesn't work, you are not an engineer, you are a "gambler" with principles. True engineers never gamble! They never leave the 0.1% uncovered or unknown.

I also had teachers trot out the line "first you have to master everything before you can do anything worthwhile", but I quickly found out this notion is hogwash. It simply doesn't correlate to the way in which many great artists work. Granted, a good half of household-name-artists appear to operate this way (at least to the layman), but innovative, meaningful, revolutionary art is created all the time by artists who never bother to learn the classics. In fact, masterpieces are often created by artists when they are in the very-young 20s. It is often through naivety that they have the guts to put out something really avant-garde.

That being said, I think that professional programmers have surprisingly little in common with creative artists, so the comparison is not worth making.

Say what you will about Jeff, however, the stackoverflow site that he produced is a testament to what he is saying. His site is probably the single most responsive site on the net. And his team created it in a span of a couple of months. You can't really tell that the code behind it is shoddy, doesn't conform to SOLID, etc...

There is something to be said about being fast to market.

On the other hand, do you feel that SubText code base is up to SOLID standards?