Some of you may have experienced the drama surrounding one of the recent stack overflow podcasts. In this podcast Joel makes this comment:
"Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles. 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."
You will not be surprised to find out that many people were very upset about this. Interestingly though, it honestly didn’t get me all that fired up because I know that Joel has basically created his online persona out of taking contrarian positions. I just figured that it was probably a carefully crafted move to drum up some online controversy and that a few days or weeks later it would die down.
I thought that until today I came across this post on Coding Horror which wasn’t so bad until I started reading through the comments. Only when I started reading through the comments did I really start to feel a sense of dismay at the current state of software development. I read about 50 different version of this:
"I’m a cowboy programmer who just wants to write my software the way that I want to write it. Sure, I might listen to other people a little bit, but I think I know better how to design software. So I’ll listen to what they have to say, take the pieces I like, and go off on my merry way."
I have never been so reminded of how immature our industry is than at this point. And I’m not talking about the individual people, I’m talking about the fact that we have sitting in front of us a really good chance at introducing a little bit of rigor into the way that we think about and implement software systems, but people just blow it off. People just want the easy way out, and they don’t want to take the time to actually have to learn and apply some of this stuff.
Check out the first comment on Jeff’s post:
I’ll tell you one thing, the Gang of Four book is probably one of my most disappointing programming reads of all time. Completely useless to me. Strange that I can have a successful programming career without understanding that book…
I wanted to fall out of my chair. You are unbelievably lucky to be in a field where the people that wrote that book are still alive. As Mehran Sahami said, it is like "Geometers living in the time of Euclid". We are now in the process of guiding our industry into a realm where we need to start having a better understanding of how systems are designed and interacted with. We can’t keep going on forever acting like we can’t take anything that we have learned from system to system or that someone else’s system has nothing to teach us. Why would you ever rely on only your own experience when you have the experience of hundreds of the greatest minds in the world at your fingertips? I would encourage you to go out and pick up some books by some of the greatest minds of our field, and then go to their blogs or interact with them on Twitter.
Whether you like it or not, you are part of this industry, and that means that you hold the keys for how others see your job and the work that you produce. If you don’t take pride in your work, and you don’t treat your work as a craft, then neither will they. They will see you as a cog who hammers out code and duct tapes his way to "success". I don’t think that this is in either yours or my best interest.
Here in Richmond we have recently re-branded one of our local groups as the "Richmond Software Craftsmanship Group". Even though we aren’t all experts, we are concerned with the overall view of our profession as a craft that should be studied and perfected. With a craft comes techniques and tools that we cannot create or think up ourselves. Sure it is all about creativity, but you need to save your creativity for when you really have a problem that other minds have not put serious effort into.
So get out there, and please, please, ask for help. Don’t pick up the GoF book and put it down in desperation. If you don’t have anyone local to help you, then go get a book that takes a more intro approach like Head First Design Patterns. Get out there and find a group that is interested in Software Craftsmanship, and if you don’t find one, then start one! Get excited about software and about design and you may find yourself taking a little more pride in your work!
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
I think most of the developers that post comments like those are 501 developers. They only work at their job and that is it!
Also, there should be passion for improvement and taking criticism about the code. I love when someone points me in the right direction.
If you are not passionate about the work you are doing then it is not worth doing it. Anyone can crank ugly code even a monkey can do that but it takes craftsmanship and experience to write CLEAN CODE.
Develop with Passion!
"I think most of the developers that post comments like those are 501 developers. They only work at their job and that is it! "
Except they are commenting on a software blog…
You Codelosophers are putting to much weight in a book that was written 24 years ago about an industry that is changing and evolving at lightning speed.
I can’t even read blog posts about the new MVC framework that are a year old without reading completely irrelevant information!
If the GoF patterns were the best thing for programming since the IF keyword don’t you think EVERY developer would know about them? Kinda like using nails to hold wood together?
The simple fact is programming and the tools available have changed a lot since 1994 and holding onto patterns crafted what must be epochs ago in programming time is like farming without a plow.
I read the alt.netty posts and follow the DDD purists and find their opinions interesting. Yet when I think about somebody writing tests first first, crafting a domain layer, adding dto transformations, mapping data access, mocking data access, and adding in a whole lot of abstractions ( just in case I need to change my database! ), here comes dependency injection… yadda, yadda, yadda just to spit out a couple of rows onto a a grid I can’t help feel that you you codelosophers have overcomplicated a really simple problem.
There is a world of difference between "good, clean code" and overcomplicated code that purists can geek out over.
Couldn’t have said it better myself!
I can’t agree more. Jeff and Joel are scaring me more than just Joel did.
They may be 24 years old but they were talking about MVC way before RoR thought about it. Oh wait, that goes back some to 1979 or so. Must not be that good seeing that is 30 yrs old. What was rails thinking when they used it?
Nice post and couldn’t agree more. Our field has way to many egos in it that think they are God’s gift to coding.
@jfar First, I don’t know what calendar you use, but 1994 was 14 years ago, not 24.
Secondly tools change, basic patterns of good OO design change very little. The fact that no developer has ever heard of the GoF patterns doesn’t mean that they are not universally applicable. People use these patterns every day without realizing it. But only when we recognize and classify these patterns do we start to form a lexicon for discussing software design that can bridge two different systems at two different companies. Also, I’m not saying that all of the patterns are applicable today, but virtually all of them are (assuming you are writing in an OO language).
To me you seem as if you are essentially advocating that we go off and design "clean" software without ever trying to learn from the fortunes and mistakes of countless others that have come before us.
This is a M.O. that has brought us to where we are now where we have a million poorly architected systems that would have turned out better if the people who built them had shared some knowledge of how to property build systems.
And I’m not advocating that you go through your system and start refactoring to patterns, that is ridiculous. Patterns are emergent, but what I am advocating is that you have no idea of what "good, clean code" is until you have learned from the experts in your industry.
Although it might be easy to truncate my argument into "people that are old are wrong" that’s just not my opinion. Its more along the lines of old ideas require constant vigilance as the world changes, new ideas are created, technology advances, etc, etc. Appropriately its Darwins birthday today, his theory of evolution wasn’t perfect, and years of science have expanded and refine what we consider evolution. The basic premise "natural selection" remained true. Just like the GoF’s "clean extensible code is good" has remained true, its just how we get there that needs constant work.
Now similarly I don’t want to truncate your argument to "because he was right about one thing, he’s right about everything".
The GoF and patterns in general are not things I have issues with. It could be said that most good code will resemble a GoF pattern. I’m sure most of us used factories before we turned a single page in that book.
What bothers me the most is posts like these break down into "your doing it wrong" just because your not subscribing to a pattern written 24 years ago. It seems that the alt.netty opinion is of accepting these patterns as "the way" without giving a thought to other patterns that may exist, patterns that simplify things, patterns that make us more productive, or finally patterns that just get the job done.
Jeff’s quoted comment about being successful without understanding these patterns is key part of any discussion about the usefulness of GoF patterns.
Like I said before, if these patterns were truly "the way" they’d be a lot more ubiquitous in the computer industry after 24 years. I’d expect to see them like nails in wood, white on rice, or even comments on blog posts.
Out of all the programmers I’ve worked with only about 5% knew what the GoF was, even less could implement a pattern by example. 90% of the programmers I’ve worked with produced functional code that satisfied the requirements. The other 5% wrote code so bad a pattern couldn’t have helped them.
There are so many other factors that go into programming success besides what patterns are used in the project. I think Ayende had a good post that described a project where TDD was used that failed and another where it significantly helped. The same is probably true for GoF patterns.
So in my head we can’t prove GoF makes better programmers, we can’t prove that GoF makes projects successful, therefore how can we put so much emphasis the importance of it?
@jfar, so your real point is that since not many developers know about the GoF design patterns, we should stop teaching them? Well played.
Anyone that argues against SOLID is ignorant, and whether their ignorance is by choice or by chance, they’re just wrong. I could sugar-coat it, but facts are facts.
I’m sick of debating about this stuff. I even had a whole blog post written, and then I threw it away. Instead, I’m just going to make it a point to work with people that understand how to write good software, and we’re going to use our knowledge to crush the opposition that thinks that code quality has nothing to do with product quality.
By the way, anyone that can’t describe design patterns, including concrete examples, should never, EVER, interview for a job with me.
Great post. I completely agree.
It is still difficult for me to believe that so many people are incredibly adamant about the use of proven design principles that lead to more robust solutions. I find it rather disturbing that such a large number of participants in the software development industry scoff at the notion of investing the time to improve the quality of software development.
"Craftmanship" is a great word to capture the essence of what is missing.
You are treating "successful" as if it is a binary value: either a developer is successful or he isn’t. But the world is a lot more complicated than that. You work with programmers who "produced functional code that satisfied the requirements"? That’s great, they produced adequate code. Why are you settling for adequate? How maintainable was that code when the requirements changed, or when live customers found bugs in production? Could changes be implemented, tested, and released quickly, with a high degree of confidence? Was the resulting application responsive to the user and easy to navigate, or just "fast enough"?
I know of no other industry in the world where the craftsman are so strongly resistant to learning from the mistakes and lessons of those who have come before. Of course the programming landscape is constantly changing, but that is no excuse for ignoring the decades of progress that has already been made and reinventing the wheel your way, because you don’t feel like investing the time to learn your craft.
After watching this debate ping around the stackoblogosphere for the past few days, I can’t actually figure out what everyone is up in arms about.
The only conclusion that I can draw from all of this is that nobody actually knows what they are doing until they’ve done it. You seem to have drawn the same conclusion here.
When people come up with a software solution that actually works well, then they try to distill what things went right and transform them into principles and guidelines. But we still don’t fully understand where and when to apply the principles and guidelines, and this is where when discussing software development everybody turns everything into a hot mess.
I have a batch script that runs nightly to update some statistics in our database. It is one function (Main()), has a SQL statement embedded as a constant, and the whole program is 70 lines of code. Any GoF patterns in there? No. That would just be retarded. Is there a unit test? Of course not, all the logic is in a single SQL statement. Just read the thing, it has no dependencies, and if I had the dollars it’d just be a SQL Agent job instead of a mini program. But it is successful: do I prescribe that procedural programming is the way to go for everything? Of course not.
Not every bridge looks like the Golden Gate. Bridge builders learn lots of fancy math and read a lot of guidance on the appropriateness and applicability of bridge designs when applied to a given scenario. This is helped by bridges falling down for thousands of years.
We’ve got the tools and the principles, but our industry is changing so rapidly that we haven’t quite figured out how to apply them to any particular situation. Which is to be expected, given that the industry is about as old as my father.
So the latest new principle was either (1) the true scripture, (2) a good idea for a particular scenario, (3) already obsolete, or (4) just something neither good nor bad that didn’t happen to destroy the project. Who can say which?
My take away? I read the blogs and the books and try to write software that doesn’t suck too badly but gets the job done within the allotted amount of time, using the anecdotes and principles that I’ve read about as guidance. There’s ugly code everywhere, but it works, and that’s the requirement.
Then I go home and drink a Yuengling.
@Nicholas Here is the problem, tools change and go out of fashion. Design patterns not so much. To say that no one has come up with anything that can be applicable over and over is to ignore all of the knowledge that has come before us.
Have you ever looked through the GoF book. The patterns are all over the place! How about Patterns of Enterprise Application Architecture? Those patterns are *everywhere*.
People shrug things off that they aren’t building a big system and so they just need to "meet the requirements", and then they end up with the "ball of mud" design pattern. Then it takes so many people to maintain that the company decides that American developers are just too expensive to throw at a problem like that. Then you get outsourced. The you’ll really need that Yuengling.
Oh, and I agree that not every application is huge and requires proper design and guidance. I follow the YAGNI principle as well. The problem is that many developers are happy to futz their way through a 100,000 line "small" system. 100,000 lines can still be hell when they are poorly designed.
@Nicholas And let me throw in one last example. I had to write an application that was a very simply program to sync up some contacts from one system to another. Well, I wrote it up front using the API from one system to the API for another. This application was all of 1000 lines of code.
But you know what, I went ahead and put a repository layer in because it took me all of three seconds to create an extra class to get my classes from the API. Later on when we found out that we needed to pay extra $$$ to access the API for one of the applications and instead we needed to read from a csv file export all we had to do was switch out the repository and everything just worked.
If I hadn’t then it wouldn’t have been the end of the word, I could have muscled through it, but when this type of situation is scaled for a 20,000 line system the savings could be huge.
How did I mess those dates up? Ooops..
I’ll reiterate that I don’t think GoF is useless and patterns are bad. My main point is that religiously subscribing to a 14 year old book is not smart and is not the only path to quality code or career or business success in programming.
Both Joel with Fogbuzz, and Jeff with stackoverflow being both either ignorant or skeptical about the importance of GoF ( whichever your opinion is ) have had successful careers as developers. Now this is in direct contradiction to your point. Jeff and Joel are bad programmers because they don’t appreciate/understand GoF.
Think about how modern warfare has changed over the last 50 years since standing armies battled it out. Although this comparison is a bit of a stretch I think "I am the best tank commander in the world but somebody is shooting laser guided missiles at me, damn…".
"so your real point is that since not many developers know about the GoF design patterns, we should stop teaching them? Well played."
Not quite. I’m saying if GoF was extremely important to programming success, more developers would know about it. The fact that a lot of developers don’t just points out it isn’t something required to know to have a successful programming career and I’m certain that extends to having a successful business.
I thought my point was clear with my wood/nail example. Let me spell it out. Every carpenter knows about nails, every programmer does not know about GoF. Nails are critical to the success or carpentry, GoF is not critical to success of a programmer.
Your thoughts about crushing the competition is interesting though. Just remember, there are tons of instances were crap code was delivered to a customer and they were absolutely thrilled that it "just worked".
Understand that because I do not subscribe to the belief that GoF is some magical programming sauce doesn’t mean I’m not interested in quality.
Heh, I’m trying not to be snide or rude but when I read this: "By the way, anyone that can’t describe design patterns, including concrete examples, should never, EVER, interview for a job with me."
I added "OR I will mock them in a professional way and say "will call you back" and never will, muahahahahahahaha"
I’m surprised nobody has mentioned this but I think the GoF patterns have more to do with maintenance of code. How does that angle play into this?
Thanks to all who have participated, sorry to highjack ingthe blog post ( I think I’ve written more words than the post ) but I appreciate the discussion. 😀
Also I guess then the argument also involved writing very pluggable systems with GoF patterns to writing small pieces of disposable code. Are these on in the same? Where do patterns and disposable code meet and/or diverge? Does the maintenance/upgrade/change factor of all of this destroy my arguments?
"Those who cannot learn from history are doomed to repeat it."
Great post, Justin.
@JFar Okay, I will agree with you that you can be successful in this industry without knowing about the GoF. If you define success as being able to pull a paycheck. And you know what, I’m not sure I’d consider that to be an accomplishment. I think that this just shows how few developers take what we do seriously.
On the other hand, I don’t expect everyone to be as committed to the craft as some of us, but there is a very minimal set of knowledge that it takes to be effective. I guess it is just a bit depressing how many people will take the effort to memorize tons of API calls to get a certification in *fill in technology here*, but can’t be bothered to read a little bit about a design pattern or look at an OO design principle.
For example, understanding the concept of composition over inheritance is a 20 minute conversation with an experienced developer. Most of this stuff isn’t rocket science! When you hear the arguments, it just makes sense.
@Justin and @JFar
I think we’re all pretty much in violent agreement here.
To take your example, I used the repository pattern (well, I called them DAOs, but let’s not split hairs) in a little mobile picker application we use to pick orders. When we suddenly took on drop shipping for another company, I just added a new repository implementation and let the user switch between contexts at startup. I was shocked at how well the abstraction ended up working. But in other applications, I’ve added the strategy pattern, but the interface makes some assumption that makes it un-implementable for some future tool and it gets redone or hacked around anyway. A good example would be a payment processing interface that I created to abstract credit card processing, store credits, PayPal, and cash/checks. The one that broke it was Google Checkout because that API is asynchronous and my IPaymentProcessor interface assumed that a transaction decision could be determined synchronously. I can’t see the future. In some cases the design pattern helped, and in some cases it didn’t, and when in doubt, I guess it is responsible to err on the side of the design pattern. In the payment processor example, I only had to extend the interface, not search and replace through a big ball of mud. But you have to cherry pick your patterns or you’ll just spin yourself in circles for days and not get anything done.
In both these examples, I was lucky in using the design pattern because it paid off in managing change down the road.
The main gist of my comment is that we don’t always know when to apply the design pattern and when not to. Sometimes it is a complete waste of time (YAGNI). Sometimes its addition makes a system too slow or too complicated (getOptionsFactory().getDefaultOptionFactory().getOptions().getValues()), sometimes its absence makes a system impossible to maintain. And this is why I drink.
If anything, I think the whole discussion has less to do with the usefulness of design patterns and principles and more to do with a design patterns and principles public relations problem. The way some people talk about them really does sound like a cult, and it can leave a bad taste in your mouth and cause a backlash, regardless of whether or not you use the principles all of the time or not.
To all the naysayers: please don’t knock it until you’ve tried it…and done it justice in your attempts.
Good reminder to all of us: http://numbnuggets.blogspot.com/2009/02/i-know-more-than-you-do.html
I can not stand the Mr. Design Patterns!
I have read the GoF. And you know what? It’s trivial.
I was already using these "patterns" when necessary without giving it a special name and trying to apply as much "patterns" as possible to a simple problem.
I’m programming since over 25 years and see a lot of code. Code produced by Pattern-Programmers is usually over designed, unnecessary complicated and bloated.
The people who blog about coding mostly produce very little of much use. The silent people are the ones who produce successful software.
Do you see Linus and all the kernel developers blogging about "Design Patterns", "AGILE", "SCUM" and other shit?
Has John Carmack blogged about endless abstraction layers with dependency injections?
What about the people who have written GCC, LLVM, Emacs, Firefox, etc. – No one of these blogs about the newest marketing shit from the latest consulting companies.
If you want to produce good software follow the "Zen of python" – but not blindly – and remember for every rule there is exists a valid exception. Sometimes there even is a place for gotos.
jfar: I attached some wood pieces to my wall last year without using a single nail or screw. I used glue.
Imagine a self taught cook who can prepare eggs perfectly. There is no doubt that they can cook and cook well.
Now imagine that a culinary student is learning proper techniques for egg cooking. They’re learning WHY the techniques work well and their NAMES.
Separately, these two cooks are skilled and can perform at a certain level.
But, what if the two cooks were combined. You’d have a "natural" who knows what good eggs should be and a "technician" who knows why they are good and has a vocabulary to discuss techniques with others.
Design patterns work the same way. The GOF books specifically states that they are not inventions but rather codifications of techniques already used.
A really skilled developer will know when to use a pattern and when it is over engineering things. If you don’t know the patterns to begin with you may be missing out.
I don’t think we are specifically talking about hooking up design patterns everywhere in the code. We are talking about continuous improvement. You can create a software that just have a single method "DoStuff" which will perform everything related to the software OR you can make the software better by using principles like TDD, BDD, SRP etc.
No one is implying that your software will SUCK bad if it does not have unit tests. We are just implying that it will have a better design and you will catch bugs more quickly if you have unit tests in place. Remember unit tests are not about testing it is more about designing the software and writing enough code so that your software will work as expected.
The principles of SCRUM, Agile Development, Pair Programming are all great principles but they have to be used in a certain way. If you are writing a tool that will have an interface for the client and you just want to get done with it and never update or upgrade it then maybe writing tests is a waste of time. But if you are writing a big application that has to be maintained over the years then writing tests becomes trivial.
You don’t have to apply all the design patterns in your single application but you should know when an application will be benefited by using design patterns.
We can find a 1000 reasons not to do anything or not to learn anything new but the fact is that computer science is a fast field. What used to be cutting edge yesterday maybe obsolete tomorrow.
@Marcus Well put!
@Scott lol, hilarious!
@Mohammad Agreed, many excuses for not using design patterns is that they are so obvious. Well, I’ve seen many a system in my day, and I can tell you that they are not. People also act like you have to go around "applying" design patterns everywhere. Again, it is this kind of misinformation that leads people to look the other way.
@Zardos: Sure, the patterns of the GoF are… patterns. The term pattern means that it is something people were already doing, maybe in slightly different ways, and someone (the 4 guys) elaborated and formalized in some way.
If you have 25yrs of experience in building software then you probably know when to apply something and when not to.
But new developers need guidance and thus need some principles that lead to maintainable, testable software, otherwise they will go in the same trial and error path that you and other followed to reach to the level you are now.
With nowadays industry, we don’t have the luxury to give to new developers 5 years of time to learn everything by themselves. Look at these things as a shortcut to experience.
Obviously, once they learned the basics, they have to decide, with a critical mindset, when to adapt something, but we are far away from that point.
It’s a damn pity that the guys that wrote Emacs, Firefox, IE, GCC and all that stuff don’t write about that, because they will bring many interesting points to the table. But that’s not something can do.
What I don’t understand is why do I have to read the Goblet of Fire to be a good programmer? What does Harry Potter know about coding?
@Simone That is an excellent way to look at it, as shortcuts to success. Companies expect developers to be productive much more quickly than before.
And I also agree that I wish many of the Emacs, Firefox, IE, GCC, guys blogged as well. And I think that many of them do.
@Patrick How can you ever expect to be a good programmer if you haven’t even mastered some magic? Jeeeeeeeeeeeeeeez.
Only two points I’d like to make.
Programmers have an innate tendency to immediately adopt a "not invented here" type of arrogance. Only from experience can this arrogance be shed.
In our lifetimes, we will see the day when most programs will not be written by people but by computers. Most Software is already too complicated for most humans to grasp. During your studies, try to figure out how to get the computer to do it for you as much as possible. Might I recommend bdd/rspec for starters.
[quote]The simple fact is programming and the tools available have changed a lot since 1994 and holding onto patterns crafted what must be epochs ago in programming time is like farming without a plow.[/quote]
Unfortunately this analogy is flawed. Patterns are a method while a plow is a tool. The agricultural [i]pattern[/i] of planting a field remains unchanged after rather more years than the GOF patterns, but the [i]tools[/i] (hand-plow, horse-drawn, John Deere with air-conditioned cab, etc) continue to evolve.
Enjoyed the post and the discssion (esp. jFar’s careful and thoughtful conterposition).
I don’t think ‘Geometers in the time of Euclid’ was said _by_ knuth, I believe it was said about him:
@Justin well written post. I think we can all agree that the Atwood/Spolsky monster exists purely to drive hits to their sites. They perform wonderfully.
I find it hard to fault people who are essentially nonconformists and have an approach to software development that has been working for them. It does seem that every quarter there’s an elevated voice (usually a consultant) on a soap box yelling about how much better X is than Y and we should all use X, and an immediate flood of blog posts followed by the commencement of the virtues of Z (the -next- big thing) against X and Y.
For my part I’ve found that a practical approach to using TDD (as in, use it) and SOLID (as in, I’ve been doing that all along just not to the freaky levels I maybe should be) have improved my work immensely and helped breath new life into coding. I could not imagine developing software any other way… but who knows where we’ll be in 5 years or even 5 months time.
@Sean I stand corrected, here is the talk from Mehran Sahami where he says the phrase: http://tr.ashcan.org/2008/12/-geometers-living-in-the-time-of-euclid.html
One of my Profs worked with the GoF, he also worked with Kerningham and Ritchie on C.
His quote on the matter is that he wouldnt trust a production system with a single line of their code.
Personally, I think some make sense for the given contexts of each pattern, some dont. And some contexts aren’t covered.
I think Joel and Jeff’s argument is that these types of guidelines allow for interpretations, these interpretations can be bent to allow all manner of crimes. At some point it doesnt matter what set of guidelines you use, there must be one "perfect Methodolgy" out there, eventually it comes down to a gut decesion of if that guideline applies. It may or maynot apply, but if all you know is the guideline you dont have the skill to make the determination.
I can’t mention enough how great this post it.
[quote]"I’m a cowboy programmer who just wants to write my software the way that I want to write it. Sure, I might listen to other people a little bit, but I think I know better how to design software. So I’ll listen to what they have to say, take the pieces I like, and go off on my merry way."[/quote]
… that applies so aptly to so many people I’ve worked with, it floors me.
First, to Tristan: your prof wouldn’t trust K&R’s code on a production system? I doubt your prof has worked on many production systems, ergo why he’s a prof. In other words, your prof’s an idiot. Don’t listen to him. And people, don’t listen to Tristan.
NO ONE SHALL EVER SPEAK BADLY OF KERNIGHAN AND RITCHIE, LESS THEY WISH TO BE KNOWN AS IDIOTS!
Second, pattern usage or not, the fundamental problem in our industry is arrogance. Period. Arrogance = closed minded = no learn from mistakes / no listen to more experienced colleagues. Patterns are great, and are useful when you know them like the back of your hand. They are like any other items in a programmer’s bag of tricks. But to get really good at [i]using[/i] those tricks, you gotta listen to others, and when you are a cocky developer who thinks they’re better than, say, the creators of the C programming language, there’s a [i]real[/i] good chance you don’t listen to others and others want nothing to do with you, ergo making you at the very least useless in any programming projects which require this thing called a "team".
By the ways, most production code is written by teams.
@Tristan You must be joking. Kernighan and Ritchie co-wrote the core of UNIX. Which means that their code is in almost every production environment on the planet in one way or another. I hope that this was not lost on you, perhaps your professor was joking.
I am one of those who believes the Gof book is not that great. It is a difficult read, many patterns are language specific and most examples are turned around GUI app (which is not what interest me the most).
None of the members of the Gof has been inspiring to me. I have attend a presentation by Gamma about Eclipse Jazz and was not much impressed. I don’t feel the gang have a great influence in the OOP sphere (outside the flame of the book). I much prefer Norvig, Sussman, MS Miller, Steele and the likes to tell me what programming is about.
Don’t get me wrong I am not saying it is a bad book …
I believe you are quite right when you say it is an immature industry.
I won’t talk about Gof book, but about the state of the industry.
In building trade, there are different levels of expectations.
Some people build a simple shed in the back of there garden, some will build there own house, other will build buildings or even skycrapers or.
If you’re usually building shed, you can eventually expect to be able to build a house, but not a skycraper.
In software development, lots of people try to make a skycraper from a shed, and eveything collaps.
We cannot force shed builder to use skycrapers, technics to do their hobby, but they should learn the job if they want to build high towers.
@Pierre Finally a decent critique of the book beyond the normal "I don’t understand them and I don’t need them." The points you make are valid criticisms of the book. The book is language (and paradigm) specific, has a few patterns that some might now consider anti-patterns, is a bit hard to follow, etc…
I think the most important contribution that book made was the introduction of software patterns to a much wider audience of developer. The fact that people are now looking for, and recognizing, patterns gives us a vocabulary for describing our applications. And as Marcus pointed out above, the patters in the GoF book were just codifications of patterns that were already in use. Thanks for the comment!
Justin, Thanks for posting this "on my behalf". I don’t even remember asking you to, but you know better 🙂
Another interesting way to consider the debate is from the perspective of hiring a new employee.
Would you rather hire a senior developer who:
– explains that they have a natural talent for programming, labeling themselves a ‘cowboy’
– or clearly discusses technology using a commonly-accepted, published vernacular?
Also, if you’re like me, you use different frameworks in your day to day development (JavaEE, .NET, Spring, Hibernate, etc). Whether you admit it/realize it/care – these frameworks are frequently built on commonly accepted patterns (such as those in GoF).
So, again, I pose the question: would you rather hire someone who truly understands the patterns *behind* the frameworks they use? Or someone who just gets by with the framework?
Who would be a better day-to-day developer? Who would be better when problems arise?
Seems like a no brainer to me.
@Andy Agreed, that is an excellent point. If the people that wrote many of these tools didn’t understand these patterns, then we would be left reinventing the wheel over and over.
Well written and very true. I think that Darwinism will tell if the old-school or the evolving ways of developing software will win in the end.
I’m personally sure which we we have to go.
I would say I agree with jFar. It seems like people are trying to overcomplicate things.
I’m not trying to say patterns are bad or whatever. I just don’t think you should follow them blindly. Moreover you cannot and you should not judge a programmer by his knowledge of the design patterns names. Please, note I said "names", not "design patterns" themselves. People are constantly talking about IoC, DI, but look, those principles are really simple and can be figured out in the process of coding by every programmer, I believe. They are just good, but common practices of programming. But there’s nothing special in them.
Leave a comment