There was a little brouhaha recently about some comments Joel Spolsky made on our podcast:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/02/the-ferengi-programmer.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/02/the-ferengi-programmer.html
The nice thing about all of the programming rules is that there almost always one that fits what you really want to do. Of course following that rule may break several others!
The way I see it the analogy of having a garage full of tools, just allows me to pick the tool I want. If I have just a few tools, well you can pound in a screw with a hammer, but a screwdriver works better, and a screw gun works even better then a screw driver.
You do have to learn to recognize which problems are screws and which are nails.
I think We stretched this analogy about as far as it will go.
Jeff,
I am wondering how you jumped from principles to rules. Rules are usually only good for beggining developers, or anything really. Principles are deeper. When you run into a situation in which you have no prior experience what do you use? Guess work seems a little hackish too me. I always fall back on first principles. Without principles how is one to improve and further the practice? Experience and talent only get you so far. Without principles one can not stand on the shoulders of giants (Parnas reference).
Also, don’t become an Amish Programmer.
That being said, if you can’t see the ROI on unit testing, then you are not acting like a professional. The one instance I will conceed is if you own your own company and design your code for interal uses, but if you are working for a in a development capacity, you should be developing good code that is maintainable, that is one of the reasons they pay us the big bucks.
Ah, if the ideal world we all pine for could only exist. Have you ever tried to explain to upper management, a non-technical supervisor, or a client, the value of maintainability? Of testing? Of documentation? Of best practices (whatever you take them to be)? Or even something as basic as clearly writing down requirements before starting development? (Rhetorical question; I’ve no doubt you’ve been in those shoes.)
They’re always all for it, as long as it doesn’t take any more time or cost any more, in the short term. But they never get it beyond that. A developer is generally given a vague set of requirements, which must be met within an arbitrary timeframe and budget. I can’t recall how many times I’ve pleaded with the decision-maker to allocate more resources for testing before deployment. Not once have I ever gotten it.
So, as a professional, I do what I’m being paid to do: get the job done within the constraints given me. That’s all the people paying me care about. If I fail at that, then I’m unprofessional in their eyes. They don’t give a hoot about whatever principles or philosophy I use to get the job done.
In practice, that often means throwing out a whole lot of things I really want to do, like unit testing. So, should I be professional in the eyes of you or other experts, or in the eyes of whoever is handing out the bucks? I’ll take the bucks. If I’ve done my best to explain what I think to the client, and they ignore it, then I’ve done all I can to be ethical and professional, other than delivering the expected result. It’s their responsibility to factor in all the variables I know nothing about and set deadlines and budget, not mine. Similarly, it’s their fault if problems arise later (as they invariably do.)
Of course, I get blamed anyway. As long as they pay me, I don’t care. It’s part of why they pay me the big bucks (to deliver as expected, AND to be a scapegoat!)
Rules, principles, methodologies, silver bullets, etc. are only relevant to me if they help deliver. That is often the case, sometimes, for some of them. Other times, as in my previous posts concerning inexperienced programmers, that is definitely NOT the case. I wish I could work with guys like you, and the others here touting SOLID, TDD, Agile, etc., who actually understand this stuff already, without requiring years of (time-consuming, expensive) handholding. In practice, I don’t (news flash: good developers in short supply).
You do understand, don’t you, that you all are the exceptions?
You want to know how to paint a perfect painting? It’s easy. Make yourself perfect and then just paint naturally. – Robert Pirsig, Zen and the Art of Motorcycle Maintenance
I can’t help thinking that a lot of this business about design rules is just misguided – you need to have a feel for design, and I don’t think it can be taught. Some people have it, some don’t. The ones that do can get better at it by practice, but for the most part I doubt that the people who are really good at this stuff have spent much time memorizing rules.
Do you think that Jonathan Ive (designer of the iPod: http://en.wikipedia.org/wiki/Jonathan_Ive) has books full of rules in his office that he consults all the time? Somehow I doubt it.
@Jeff R et al
Please don’t confuse the principal with the implementation of the principal. The SOLID principals are sound…the difficulty in making them happen is your own creation.
SINGLE RESPONSIBILITY - DON’T MAKE A BIG BALL OF MUD.
OPEN CLOSED - DON’T MAKE A THING THAT CAN BE INADVERTANTLY TROUNCED BY ANOTHER THING.
LISKOV SUBSTITUTION - WHEN POSSIBLE MAKE THINGS MODULARLY SO YOU CAN CHANGE LESS LATER.
INTERFACE SEGRATION - DON’T MAKE A CLIENT DEPEND ON INTERFACES THEY DON’T NEED.
DEPENDENCY INVERSION - DON’T MAKE SOMETHING CONCRETELY DEPENDENT ON SOMETHING ELSE, RELY ON ABSTRACTIONS
Those make sense…which pattern you chose, how you actually get it done are language issues and shouldn’t be confused with the difficulty of understanding the principal…which I disagree with you, they can be taught in minutes…the how might take longer if they don’t know the common pattern solutions, but that’s a seperate issue.
And again…like has been said…they are principals not rules. A subtle but important distinction.
For my money SOLID principals fall into the same camp as Write the code as though the guy who is maintaining it is an axe murderer who knows where you live.
http://www.codinghorror.com/blog/archives/001137.html
http://www.codinghorror.com/blog/archives/000610.html
I’m currently working on an ASP.NET MVC based product (read: site) and after hearing/reading many of blog posts about this rule, that rule, this idiom. I thought that for a new project I’ll try to follow them. After about 3 weeks of coding I feel like I had gotten nowhere and everything was just so over-complicated. Then it hit me…
I’m experienced, I’ve been programming since my Commodore 64 and QBASIC. I don’t need a set of rules to help me make sure my product is flexible, reliable and easily maintainable. I can do that with my own judgment and insight.
I completely agree with what you said Jeff. I just hope others finally realize like I did that these rules really only hold back the experienced programmers.
they are principals not rules. A subtle but important distinction.
I see the point several of you have made about the difference. It’s a good point. I’ll have to think about that, and on how to use the terms more precisely. Learning something new every day.
Ferengi in Hindi means white guy.
Rules/Principles are not in themselves bad. Used wisely, they make life easier.
People who form a naive and concrete fixation on the one true way based on parroting but not really understanding said rules - often forming a circle and parotting the rules together around a great big whiteboard - that’s bad.
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
- Bertrand Russell
I agree with you about the importance of not become in a Farengi
But thsi quote is a really bad moment
Quality Doesn’t Matter That Much
You cannot say in any proffesional context and not to expect to be hardly criticized
The irony is that you are probably using this principals, but by another name. The goal of them is to get to that flexibility you mentioned. If you know the principal as another thing in another shape and form…good on ya.
I think it’s a common trap for beginner and experienced a like to try to take a ‘new’ concept and apply it too liberally and rigidly.
This is such a strawman.
Programming is complicated. There are different levels of complexity though. The simple contact form that takes a few fields and saves them to a database and/or email is on the low end. It doesn’t need any of the above principles. Enterprise applications with complex business rules and multiple integration points are on the other.
OOP, DDD, SOLID and other design patterns and techniques are principles that gear towards the more complex. Yes there will be dogmatic programmers that learn the singleton pattern and try to use it for everything. That’s no reason to disparage the learning or use of patterns. I agree that critical thinking is still required, but Joel again has missed the point. These principles are something that help developers write better code for more complex solutions. Once they are absorbed, the developer no longer has to adhere to them as a dogmatic set of rules. They become part of him.
This goes hand in hand with Joel’s statement quality doesn’t matter. As others have already mentioned, that’s just plain irresponsible. I think thats because joel either doesn’t do much real programming anymore, or he just hacks crap together. Quality does matter. I’m stuck maintaining a very low quality application that could use a few of those patterns and principles, and the lack of quality costs the client money, money, money.
How do you write higher quality code? By learning principles and practices that other, more experienced developers discovered before you. Same as any other industry.
Bureaucratic programming. Please. The majority of developers do not suffer from too much design patterns, or too much SOLID, or agile, or waterfall for that matter. They suffer from whipping out cowboy code in a pure chaos environment, using simplistic drag drop, data driven, vb-like techniques.
OMG! A Pirsig ZATAOMM fanboy posting here, followed shortly thereafter by a Bertrand Russell quoter. You guys just made my day!
Here’s another from Russell, then I’m done pontificating on this thread:
The secret of happiness is to face the fact that the world is horrible, horrible, horrible.
Maybe the issue with those that try to follow these rules dogmatically and use them everywhere is that they are trying to tackle it all at once. Start with one. See if and where that helps you. Then add another. And another. Soon you’ll find the way you program has slowly changed for the better.
I can’t decide on this debate. Is there some publicly available code representing the two sides we could judge against each other? Maybe even Jeff/Joel code versus Uncle Bob code?
I like Andy Hunt’s view of the subject: the people who need the most context-free rules are the absolute beginners (this is from Pragmatic Thinking and Learning: Refactor your Wetware)
I would be more willing to take this article seriously if Jeff and Joel could show some evidence that they actually know what these principles are. Sorry, but linking to them is not sufficient evidence.