February 11, 2009
There was a little brouhaha recently about some comments Joel Spolsky made on our podcast:
Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles. (That's a real easy-to-Google term!) It's object-oriented design, and they're calling it agile design, which it really, really isn't. It's principles for how to design your classes, and how they should work. And, when I was listening to them, they all sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly.
There's nothing really objectionable about Bob's object-oriented design principles, on the face of it. (Note that all links in the below table are PDFs, so click accordingly.)
While I do believe every software development team should endeavor to follow the instructions on the paint can, there's a limit to what you can fit on a paint can. It's the most basic, most critical information you need to proceed and not make a giant mess of the process. As brief as the instructions on a paint can are, they do represent the upper limit of what most people will realistically read, comprehend, and derive immediate benefit from.
Expanding from a few guidelines on a paint can into a detailed painting manual is far riskier. The bigger and more grandiose the set of rules you come up with, the more severe the danger. A few broad guidelines on a paint can begets thirty rules for painting, which begets a hundred detailed principles of painting..
Pretty soon you'll find yourself believing that every possible situation in software development can be prescribed, if only you could come up with a sufficiently detailed set of rules! And, of course, a critical mass of programmers patient enough to read Volumes I - XV of said rules. You'll also want to set up a few messageboards for these programmers to argue endlessly amongst themselves about the meaning and interpretation of the rules.
This strikes me as a bit like Ferengi programming.
The Ferengi are a part of the Star Trek universe, primarily in Deep Space Nine. They're a race of ultra-capitalists whose every business transaction is governed by the 285 Rules of Acquisition. There's a rule for every possible business situation -- and, inevitably, an interpretation of those rules that gives the Ferengi license to cheat, steal, and bend the truth to suit their needs.
At what point do you stop having a set of basic, reasonable programming guidelines -- and start being a Ferengi programmer, an imperfect manifestation of the ruleset?
Like James Bach, I've found less and less use for rules in my career. Not because I'm a self-made genius who plays by my own rules, mind you, but because I value the skills, experience, and judgment of my team far more than any static set of rules.
When Ron says there is an "absolute minimum of practice" that must be in for an agile project to succeed, I want to reply that I believe there is an absolute minimum of practice needed to have a competent opinion about things that are needed -- and that in his post he does not achieve that minimum. I think part of that minimum is to understand what words like "practice" and "agile" and "success" can mean (recognizing they are malleable ideas). Part of it is to recognize that people can and have behaved in agile ways without any concept of agile or ability to explain what they do.
My style of development and testing is highly agile. I am agile in that I am prepared to question and rethink anything. I change and develop my methods. I may learn from packaged ideas like Extreme Programming, but I never follow them. Following is for novices who are under active supervision. Instead, I craft methods on a project by project basis, and I encourage other people to do that, as well. I take responsibility for my choices. That's engineering for adults like us.
Guidelines, particularly in the absence of experts and mentors, are useful. But there's also a very real danger of hewing too slavishly to rulesets. Programmers are already quite systematic by disposition, so the idea that you can come up with a detailed enough set of rules, and sub-rules, and sub-sub-rules, that you can literally program yourself for success with a "system" of sufficient sophistication -- this, unfortunately, comes naturally to most software developers. If you're not careful, you might even slip and fall into a Methodology. Then you're in real trouble.
Don't become a Ferengi Programmer. Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they're never a substute for thinking critically about your work.
Posted by Jeff Atwood
I think you may not understand those principles and therefore don't understand the value of them. The all have to do with architectural decision a programmer makes. Saying the rules of the language and compiler are enough doesn't really cut it. Knowing and understanding good programming principles and patterns is part of the growth of any good developer. And these are principles not rules, the rules are already built into the compiler. Even Bob will break a principle if the problem requires it.
At least we're not arguing about how GO TO should be eliminated from all code anymore. That's progress.
I found much of this amusing. Dr Johnson said: Clear your mind of cant. Many of your poster's minds seem to be straitjacketed by either religion or methodology. Statistics will tell you, almost everything you believe to be true is wrong. (90% anyway)
When I first start programming professionally, I had no clue about design principles. When I started seeing a lot of the code I wrote blow up in production environments and then see a ton of bugs get introduced every time I added one simple feature, made me want to quit. Then I did the right thing and started to read about programming and take an *Active* role in making myself better. Some of those design principles I figured out myself. Some of the TDD methods I figured out before I even heard what TDD was. Some of the OOP concepts I learned without even knowing that's what they were called.
I didn't go to college until AFTER I was already in the field for about 10 years.
Now I teach younger developers about these principles and how not to suck when I hire them because I'm now the manager...
You don't need a book about SOLID design principles to be a good software engineer. You need to think and learn for your self. Pick up a book when you are stumped or don't know where to turn next. If you are truly a software engineer, then you will get the most enjoyment out of the discovery, not the end result.
At least, that's how I see it.
This post made no sense apart saying that rules limit your freedom.
That is true, and also limit (slightly) the enjoyment of programming.
The reason is that the enjoyment you perceive comes from complexity. Sometimes I caught myself making my life a bit harder because I want to enjoy a bit more the programming. Not looking up at a solution or THE way other solved a problem straight away and trying some fantasy solution first is more fun. I agree here. But you should be a grown up senior programmer and live with it.
As a counterpart, when you do a perfect design at the start and follow good consistent guidelines (when and where you agree with them), you get a sense of cleanness and the software has a sense of wholeness that make up for the lost enjoyment for complexity. Which leads you into unmaintanable code. Also you have a sense of superiority to the 99% of bad programmers trawling around. And you have a quicker and better career.
Using good (and internalized) guidelines (for me are SOLID and DDD) give better and more maintainable results, this is an hard fact.
The more the software should be changed in the future and the bigger the size of the project the more you should stick to them. No questions here. For big software projects (that last many years and have continuos versioning) 90% of work is maintenance and coming up with new versions. You only build it once, and that is 10% of the time if you account a period of only 5+ years and built the first version in 6 months (common timeframes here). If you dont get it right you might even have to live with a bad design for all those years and be slower at improving your software.
I'm very happy many programmers like you don't understand this, I can keep being happy with my sense of superiority.
Jeff, I enjoyed this metaphor. I doubt you can really appreciate how well it touches reality like some of us, but spot on. Now...will you be getting sued too?
Thanks for thinning the market by saying things that will make rookie programmers dumber. At least I won't have to worry about competing against them in the market, since I will own their asses in every way.
I have to agree with you and Joel on this. Today most so-called programmers talk of design patterns without knowing when to apply which and more importantly when not to apply. They talk about agile programming not realizing their downsides in certain situations. Good programming is not by fixed set of rules, it is dynamic in nature and adapts according to external factors and internal constraints. People espousing big theories have normally lost touch with actual programming imho. More on it later but I am feeling tired now.
Hi guys. Do something every day that you don't want to do; this is the golden rule for acquiring the habit of doing your duty without pain. Help me! I find sites on the topic: kitchen islands. I found only this - a href=http://kitchen-islands.info/Buy-kitchen-islands/Kitchen-islands-design-on-wheels/Kitchen islands design on wheels/a. Easily compare and save on cheap airfare. Our travel agents or travel agency will search the lowest discount airline tickets for your trip. Waiting for a reply :mad:, Nicola from Senegal.
Hey. Keep your broken arm inside your sleeve. Help me! It has to find sites on the: Search for best flight deals, last minute airfare and save big on your flight booking.. I found only this - a href=http://kitchen-islands.info/Moveable-kitchen-islands/Custom-kitchen-islands-rugs/Custom kitchen islands rugs/a. Whichbudget brings you all the cheap flights with budget airlines in one place, linking over european. Payless for your airline tickets! Discount airline tickets. With love :mad:, Pin from Western.
Whoo this must be one of the largest religious shitpiles of the internet.
1. Never ever go negative on something you dont understand.
2. Use the right tool for the job. Regarding SOLID, It is just one set of tools in the programmer toolbox. It will like any other powerful tool kill a project if overly and wrongly used. It may also like any other powerful tool help a project if rightly used. So stop arguing and use the right tools for the job.
"...The Ferengi are a part of the Star Trek universe, primarily in Deep Space Nine. They're a race of ultra-capitalists whose every business transaction is governed by the 285 Rules of Acquisition. There's a rule for every possible business situation -- and, inevitably, an interpretation of those rules that gives the Ferengi license to cheat, steal, and bend the truth to suit their needs...."
WOW it sounds like my country, Italy, not a different galaxy, after all! ! !
really fantastic posting, that is so wonderful.
The problem I have with Agile is that they try and sell the idea that there exists some single set of universal principles that can codify the construction of software. They try and sell their principles as some sort of Newtonian Gravity for software development. The insinuation is that if you don't adopt these principles, your project is going to fail.
The problem is that there are a huge number of counter examples.
For example, Linux is a successful project where nobody is in the same room together, where there are no scrum masters, where there is no unit testing and where pair programming is almost never done. Yet, it's successful.
In fact, it's laughably easy to find successful projects that are almost anti-xp. Where there so far away from being Agile that they're in a whole different universe.
I'm not sure what these people are trying to prove.
what? there's stuff on a paint can besides the colour? who knew...
Oh, man! SSW has good intentions, but seems a tad overly prescriptive.
Machine doesn't care how you code, only people do.
What's the difference between a 100,000 line monolithic app versus an object oriented one spread across many classes and interfaces to the a machine?
Machine is not baised toward patterns or code organization, it just compiles and runs.
Only humans care about Patterns, Practices, Principals.
Who do you talk to when you code? The machine or the humans? The machine.
So, maybe that's Jeff's point.
However, trying to make you code readable and maintainable for humans is a big challenge and that is where the pattern, practices, and principles come in. They should be there to help and guide one toward coding nirvana.
No one likes debugging, maintaining, and fixing obscure or spaghetti code.
It is completely disingenuous to start with Uncle Bob's SOLID principles as the header to a rant against too many rules in software development. If you don't understand those design principles it doesn't matter if you use a code repository and can build several times a day. You are still going to end up with unmaintainable crap.
Anybody who has a clue knows this.
It is true, the machine does care. Nowadays the average programmer is so far away from the machine due to frameworks and abstractions that optimization at a low level doesn't really exist unless your writing a missile guidance system in C or even at a lower level in assembly.
For the majority, programming is:
Without Intellisense I think you would be down to a handful of hardcore programmers.