First time here? You are looking at the most recent posts. You may also want to check out older archives or the tag cloud. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS. Thank you for visiting! (hide this)

UPDATE: Stackoverflow #41 is out. I bet it's going to be the most listened episode ever.

This morning I woke up, and suddenly I was flooded by tweets and posts. All of that were about the latest buzz of the moment: “Are Jeff and Joel going crazy or are they just playing going crazy?”.
I just want to think that, at least Jeff, is just playing the devil’s advocate, and giving a voice to the silent crowd that thinks that “getting things done” and “ship the product/project” is more important than crafting a good piece of software that can be maintained for long time. I HOPE it’s just that, and he is exaggeratedly pushing the opposite to try and reach a better balance between the two opposites.

First thing I want to make clear my position on the ALT.NET thing. When ALT.NET came out two years ago or so, I was skeptical at first, because I thought that, while the idea behind it was great (and it proved to be great), it was useless because 90% of the developers don’t care about their job and thus they do the least amount of work in order not to get fired. But then I decided to try and spread the word myself.

What happened?

But going back to the topic of that post. I’ve an opinion about this, so, if you want you can skip directly to it, but if you want to form your own opinion, I’m going to summarize the main episodes of that saga:

  • I think it all started back in October, when Jeff was talking about his experience writing StackOverflow, and said that he didn’t care that much about security and about making the software flexible because he wanted to push the site out as quickly as possible. Scott almost felt off this chair when he heard that, but Jeff assured that the refinements (aka refactoring) would have come later.
  • Then, still on Hanselminutes, Bob Martin talks about the SOLID principles, and how they help writing good, maintainable, testable software with almost no effort. IMHO the best explanations of these principles I’ve ever heard, really recommended
  • In StackOverflow Podcast #38, Joel, commenting on the just mentioned podcast, states :“Quality just doesn’t matter that much” and also that this is leading to “extremely bureaucratic programming”, and many other comments like this.
  • This podcast obviously started to wake up the nest of hornets that is the community, but the first that really noticed and commented about this outing was Mr. Uncle Bob in person, which answered with the post: “Quality Doesn’t Matter That Much” — Jeff and Joel. He also wrote an “An Open Letter to Joel Spolsky and Jeff Atwood” to try and bring is points on. He also suggests to be invited to talk at a future episode of the show, but till now nothing happened yet and it was interviewed in episode Stackoverflow #41.
  • But the proverbial last straw was Jeff’s answer to Bob: The Ferengi Programmer. I think he is correct when he says that you don’t have to stand on giant’s shoulders but that you have to have a critic mind, and adapt to the environment. But he speaks to 124 thousands readers, the vast majority of which don’t read other blogs (Codebetter only has 30K, 1/4th of Jeff’s readers), and I guess they didn’t hear anything SOLID before. What they got (even if Jeff didn’t explicitly said) is that Principles, Pattern and all that stuff is useless and cumbersome, and only slows you down when you have to write code that has to ship.
  • Obviously this post didn’t go unnoticed as the others, and quite a few people wrote their thought about that:

We are like house builders at the time of Egyptians

I think it’s good that Jeff and Joel started this conversation, because it might help our industry grow a bit.
We are (to continue with Rob’s analogy) in the position of the first house builders at the times of the Egyptians: we are still experimenting and trying to find the best way to build software. Some Egyptian builders applied all the principles they had at the time, using good stones, with the correct design. Other used cheap wood, hold together by ropes, and the house was build just putting on piece on top of the other. The pyramids costed more money and took more time than the wooden house, but they still stand after 4.000 years, while the other houses probably went destroyed at the first sand storm. After thousand of years of tries and errors, house builders can now apply the right principles for each kind of house so that the quality of the house is balanced by the time and effort spent building it. Probably we will never have a pyramid that can resist 4.000 years (since we understood that applying all the principles can lead to higher costs and longer times), but also we don’t have houses that goes down at the first blow of wind.

But in Software Industry we are still experimenting: probably we will fall in the error of over-using the principles (as it happened with the building industry centuries ago), and then we will move back to balancing the two things, and using only the principles that matter.

The first paintings of the great masters were all classical paintings

But in order to be able to decide which rule and which pattern not to apply, first we have to master all the rules. Only after we have them in our skillset, we can decide whether to apply or not apply a certain principle because we don’t need it. At school I was always taught:

If you look at the history of painting you’ll notice that all great painters’ first paintings were classical paintings. Later they experimented different techniques, and finally they invented their own style.

Last final words

Probably I went to far on this post, and it also took me 3 rewrites to get it to this point, but what I just want to summarize here is that IMHO SOLID principles are good, and that must be in everybody’s toolbox. It’s no point in reinventing the wheel every time. But also pay attention to no overuse them, and apply them with grain of salt. But first... LEARN THE BASICS

kick it on DotNetKicks.com

Technorati Tags: ,,

posted on Thursday, February 12, 2009 3:29 PM

Comments on this entry:

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Ryan Lanciaux at 2/12/2009 4:23 PM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Mendelt Siebenga at 2/12/2009 4:26 PM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Simone at 2/12/2009 5:12 PM

@Mendelt: you are right... principles aren't rules... that makes his statements even dumber.

@Ryan: guidelines are formalization of decades of tries and errors, not something made up just because someone woke up one day and decided he didn't have anything better to do than invent the SOLID principles.

If you don't follow them, and experiment by yourself, it might take 5-10 years before you realize that you have to build software in a certain way in order to be testable, maintainable, etc...

They are not a replacement to real experience, but they do help reaching a professional level quicker than just with failures

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Emanuele DelBono at 2/12/2009 7:09 PM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Rob Conery at 2/12/2009 7:11 PM

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!

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by raffaeu at 2/12/2009 8:37 PM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Simone at 2/12/2009 9:08 PM

@Rob: 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. Users are accustomed with bugs having software (look at all the Microsoft software) so they are fine if you software has a bug.

I wonder how they develop software for medical appliances or for aircraft. But probably this doesn't matter that much because, opposed to the usual LOB applications, in that situations I'm pretty sure the customer doesn't change mind every day, so a very big design upfront, with a big set of documents will probably is enough.
But this approach will not be possible where the average customer change mind every day, and want the software that drives his business to be cheaper then the SUV he buys every year with the revenue of his business.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Rob Conery at 2/12/2009 9:48 PM

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

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Justin Etheredge at 2/12/2009 9:55 PM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Kevin at 2/13/2009 7:14 AM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Mike Furmedge at 2/13/2009 10:03 AM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by LorenzoC at 2/13/2009 10:41 AM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Simone at 2/13/2009 11:21 AM

@Kevin: SOLID is about application design, not about unit testing, acceptance testing, UI testing. It's not the solution for all the problems of mankind, but it helps doing what you mentioned.

As for the comment on breaking the rules, I'm not saying that you don't have to break them: the title of the post says that in order to break them, you have to know them first.

All this debate came out by the fact that someone said that rules are useless.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Simone at 2/13/2009 11:29 AM

@Mike: the problem with common sense is that most people don't have it. And for many people, building "good" software is not their priority.

So what it might be "common sense" for you and me, might not be the same "common sense" of some with other priorities.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Gergely Orosz at 2/13/2009 1:07 PM

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

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Pop Catalin at 2/13/2009 5:49 PM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by cbp at 2/15/2009 12:37 AM

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.

# re: Do you wanna be the Picasso of programming? First learn the rules, and only after break them

Left by Robert G at 2/16/2009 9:25 AM

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?

Comments have been closed on this topic.