Thus, if you read the article, you are most assuredly in the twenty percent category. The other eighty percent are not actively thinking about the craft of software development.
True.
Thing is, at least 95% of useful and functional software is produced by that 20% of people. The other 80% are not really in the business of producing software, they are in the business of ‘sitting in an office’.
Say if you are interested in marketing products and services. These can be genuinely useful or snake-oil; from a marketing perspective it makes only a subtle difference.
If your products/services are, or claim to be, useful for software development, you aim at the 20%. If they are aimed at ‘sitting in an office guy’, then he is just a small niche within the larger set of people who sit in offices not doing much. The key products they require are chairs, coffee, and time-wasting web apps.
It’s the job of the lead programmer or manager to see that good principles are followed, perhaps by guiding others invisibly, without explicitly mandating or even mentioning those principles.
This is still wrong.
The statement above says,
Good principles will be enforced see that good principles are followed
Do not explain the good principles being enforced without … even mentioning those principles
The lead or manager should NOT avoid mentioning and discussing the underlying principles he’s expecting his team to leverage.
I suspect that success is much easier to achieve if it has been clearly defined.
Sorry, I don’t get the Nambla joke. Would anyone care to explain, please? I am feeling quite stupid now. I guess this means that I definitely belong to those 80% inferior beings. No irony intended.
I think you’d want separation of concerns in there too and that plus DRY should give you the basics of OOP too.
As a programmer who never went to uni I started off with DRY and it gave me plenty of distance in telling me how to structure code.
SoC came later when I realised that mixing GUI and database code wasn’t really working. KISS unfortunately only came to me later when working in large teams and asking myself if others would understand the code and YAGNI is for project management, timelines and your role as a developer.
The get shit done philosophy applies to any job really so doesn’t live here.
It’s interesting to pull this stuff apart, look at MVC for example, that’s basically just SoC, State pattern is a bit of DRY and so on.
I agree that you can trust in DRY, KISS, YAGNI and SoC. Everything else requires a bit more cynicism to see if it is relevant and useful.
I don’t want to mischaracterize what you’re saying, but I interpret it, in a nutshell, like this:
There are millions of programmers who are nine-to-fivers who don’t care about there craft;
These are the people who would most benefit from learning guidelines and method of some sort, but are also those who are least likely to learn them, or indeed even read about them;
I agree completely, but that does not devalue guidelines and methods that exist. And:
Those of us who care about our craft and make an effort to learn need to carefully consider methods and guidelines, rather than adopting them blindly.
I also agree. I don’t follow any single methodology end-to-end, but I do read copiously, try different things, and adopt those that appear to make a difference to my work and drop those that do not.
The problem, I think, is that for a lot of people what you are suggesting would amount to a license to disregard method and guidelines without the careful consideration and continuous learning that most people who care about the craft should follow.
Programmers are not the problem. The problem is the continual interruptions by management, marketing and sales people - who, all believe, that programmers can and should be interrupted at any time, work overtime with no pay, be subject to environmental conditions which are not conducive to creativity nor productivity.
When those road blocks are removed, then and only then will real productivity and creativity begin to emerge. Not any of this agile or scrum crap.
Ok, so we’re suppose to keep our programming simple so we have more time to rape teen boys? Or, just have more time to joke about it? I’d appreciate if you could expound upon your last point. I think there are a few confused people here.
And how do we expect the average developer to find out about these? In a word, marketing.
Through education, otherwise they have no business working as programmers.
So, if we know the programmers who would benefit most from these rules and principles and guidelines are:
highly unlikely to ever read them of their own volition
almost impossible to reach through traditional religion/marketing
Then those programmers should not be programming. Some minimum of professionalism is required, otherwise the business as a whole reflects this (and I think it does so now).
I think we would be doing these people a disservice by catering to them through any kind of marketing, except maybe word by mouth, but then that’s how people always woke up and found out about how to do things better, or just new interesting things.
I think we can interpret Jeff’s post in the other way around.
It’s not that principles like SOLID are bad, redundant or anything, just that their goals are all the same. To educate developer to write a ‘quality’ program that easy to read and maintain. That’s DRY, KISS and YAGNI.
Though, having so many principles to follow has some draw back. Some people just don’t try to understand them well before using them. I’ve met some developers who are so zealous about some ‘design patterns’ and ‘principles’ and make their program an over designed piece of junk that suffered anyone who try to maintain it.
Maybe it’s just that these programmers don’t put enough effort understanding these ‘principles’, or maybe it’s just that there are too many things for them too learn and make them forget the very basic things like DRY, KISS and YAGNI?
Could someone who actually agrees with this post, please give a non-trivial example of how not adhering to any of the SOLID principles leads to a better design?
Agreeing with the point Jeff is making is not the same as deliberately avoiding all the SOLID principles (or similar ideas that have emerged from software engineering experience over the years). It certainly doesn’t mean believing that avoiding them leads to better design.
To me the basic point here is that there are no silver bullets. You always have to think about what you are doing, and if you should find yourself in a situation where breaking some principle gets the job done better, then don’t be afraid to do that.
I’ve spent years trying to increase acceptance of Agile fundamentals in developers with traditional OOP backgrounds. These people are not unreachable - they do read and think about software development, and their ideas have merit. Endlessly chanting YAGNI! will NEVER bridge the gap.
What can? Show them how design can evolve. Write clean, maintainable code using Agile techniques. Demonstrate how TDD reduces defects and enables refactoring. Understand and speak their language.
Doctors have to learn the Latin names of body parts, as those are part of the technical vernacular of the profession. Arm bone just isn’t specific enough. Terms like Strategy Pattern or Inversion of Control can provide the same benefits to communication in our profession.
There is a huge flaw in your thinking. For programmer to know how to keep from repeating herself, to know how to keep it simple, to know she ain’t gonna need it, and yes, even to love a boy, she needs to study and understand a core set of programming principles.
At the core of this Jeff I don’t think you really believe what you are saying. You’re baiting us–and man is it working. You’ve hit on a formula to generate noise about you and your blog.
StackOverflow is superb and I respect you greatly for the work and time you’ve invested there. As a blogger, though, you’ve become the technical version of the ShamWow guy. You’re carnival barking for your brand.
I didn’t recognise your acronym #4 and looked it up on wikipedia. For what it’s worth I am upset about this attempt at a joke and I wish you hadn’t done it.
I read quite enough vile twisted sick stuff in one day just by looking at newspaper headlines.
While I agree in general, the whiff of elitist backpatting does bother me a bit.
Various methodologies are not really about programming at all, and even the most brilliant coder can benefit from thinking and using them. There are many activities related to getting good, robust, code out the door that satisfies customer requirements, and in my opinion the programming part is only a smart part (just like good construction is only a small part of what makes, say, a successful automobile).
Sure there are common principles throughout. In Carlin style we could probably whittle these down to be excellent. But the actual formulation of this principles into guidelines provides a framework that all parties (customers, programmers, testers, config managers, project managers, et al.) can understand and follow.
If it was easy as expecting people to just do the right thing we wouldn’t have any of these methodologies and every project would succeed.
I think part of the problem with software development and the reason we’re having these discussions is that the barrier to entry is just too low. Anybody can download some free tools, put together a program and distribute it widely.
Many people think software development is not an engineering discipline but a craft or some form of creative art. Would you let anybody step into your shop and use your table saw or your lathe? If so, would you expect that anything good comes out of it. I was watching Jacques Pepin one day and he said that after years of apprenticeship he graduated to the stove.
And even if you agree software development is an engineering discipline, it’s still way too easy to become undisciplined and lazy. The guy in the cube across from me designs plastic parts for our products. When he finishes his CAD work and releases the design we have a thorough design review. The mold guys get involved and figure out if it’s ok to build a mold that costs hundreds of thousands of dollars.
Another guy is designing circuit boards. A board turn involves circuit design, PCB layout and fabrication and board stuffing. There’s a huge cost and several months of cycle time.
Do you think the guys doing mechanical and electrical engineering should just throw the principles overboard and do what feels right. Maybe just build a few molds and see how it goes?
If you answered No then why should it be different for software? Because the website or app you’re working on will be obsolete soon anyway?
This debate is way too polarized and I think the far ends of the spectrum would learn a lot more from each other if there were less loaded words being flung around and more seeking for common ground (my longer-winded way of saying this is at http://www.above-average-software.com/articles/read/the-goldilocks-principle). I find both sides of the debate hard to stomach at times.
In the end, I don’t think you can’t rely on successful people to accurately communicate why they are successful. Having Jeff or Joel or Uncle Bob or Linus or Anders or a lot of other successful programmers tell you what they think works, whether Jeff’s keep it simple stuff or someone else’s 98 page thesis on the best practices of writing generic mock unit test framework interfaces… they’re probably wrong about why what they have done has worked for them. Trying to copy what they say they do is just cargo cult programming taken to a higher level.
The success or failure of software projects probably has more to do with management of teams than with the practices of the coders involved. I think it’s more important that the team you’re on share a philosophy and style than what that philosophy and style are.