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.
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.
@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…
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
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.
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…
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.
@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.
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!
The plural of Jeremy is NOT Jeremies.
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
Also, object oriented programming dates from at least 1967
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.