Stack OverflowAre today's young programmers getting wrapped around the axle with patterns and practices?
[+43] [23] Robert Harvey
[2009-07-08 01:55:57]
[ design-patterns ]

This question exists for historical reasons as it was valuable to the Stack Overflow community during the evolution of the site. It is not an example of an objective, on topic question and should not be used as an excuse to post something similar.

Recently I have noticed a number of questions on SO that look something like this:

I am writing a small program to keep a list of the songs that I keep on my ipod. I'm thinking about writing it as a 3-tier MVC Ruby on Rails web application with TDD, DDD and IOC, using a factory pattern to create the classes and a singleton to store my application settings. Do you think I'm taking the right approach?

Do you think that we're handing novice programmers a very sharp knife and telling them, "Don't cut yourself with this"?

NOTE: Despite the humorous tone, this is a serious (and programming-related) question.

(2) Programming-related?... yes. Subjective?... VERY YES! Should probably be a wiki. - gnovice
(1) Since when is IOC, DDD, and a singleton a sharp knife? If you really want a sharp knife, let go of static typing. - Todd Stout
(4) Ouch. Well, static typing is more a world view than a design pattern isn't it? As in, your world view is great, mine sucks. Kinda like the Dems and Reps. - Robert Harvey
While it might be a bit overkill for a small app, I think the question askers design approach to his app isn't that bad. It sounds like he is doing it to learn more about those things he mentioned and I'm all for that. Why not have him learn about TDD, IOC, etc? - Simucal
(1) Agreed, with the proviso that the exercise will not teach him when it is appropriate to use these patterns, and when it is not. - Robert Harvey
(26) Sharp knives are easy to work with. It's the blunt ones you accidentally cut yourself on. :p - jalf
(1) What's wrong with static typing? - Tim
Design pattern are very usefull, i found this out when i was first interviewing for a job. half of them asked me some stupid questions about design patterns. so i think novice should use design pattern whenever they can(even if they are not needed)to get to know them better so they can use it when it counts(job interview). - IAdapter
(1) I think you made my point. - Robert Harvey
My understanding of TDD is that it prevents the dev from going overboard. The idea is to code only what is necessary to get the test to pass, so they shouldn't be introducing complexity until it more than compensates for the loss in understandability of the code. Thus it forces simplicity (ideally). Of course, it requires testability of the code, thus MVC and IOC derive naturally from that starting point (but the dev doesn't need to use any tools for MVC and IOC, so the code could remain simple enough for a maintainer to approach). - Pat
[+96] [2009-07-08 02:05:55] womp

If patterns, testing, managed languages and best practices is handing them a sharp knife, then at least they can cut with it.

Compare that to the unmanaged spaghetti C and Perl that I was taught in University - they handed me a spork [1] and told me to butcher the cow!


(5) +1 just for the funny. - HillBilly.Developer
(28) +1 for using "spork" in a coherent sentence. Oh, and right on. - GalacticCowboy
+1 - you are so right... - Otávio Décio
Was it a dangerous hybrid? - Blorgbeard
(4) Best practices is good and is fundamental. But misunderstanding TDD & patterns is bad. There's a reason TDD is something considered best done by senior-level coders. I'd rather have somebody who's solid with quality comments, robust logic, and readable code than someone who's mediocre but can rattle off the various GOF design patterns. - hythlodayr
+1 Yes...I agree. I wish I knew about all of this stuff when I got started...and had a site like this so that the people that did know would happily teach me. - Andrew Siemer
(5) I think it's spam that you butcher with a spork, by the way. - Nosredna
@hythlodayr - absolutely agree. My point is more that at least they come out of school knowing something about them - I (and probably a lot of others here) had to learn all that outside of school. Noobs writing unit tests are just as bad as noobs writing code, but hey, gotta get that experience somewhere. @Nosredna - oh sure, hindsight is 20/20 :p - womp
(1) I'm now going to walk around and say "spork" a bunch. Spork. - kyoryu
[+71] [2009-07-08 02:50:47] Duck [ACCEPTED]

I sense something of an age/generation divide on this.

Twenty years ago you knew someone was a bad programmer because they came to work and wrote 25 C programs that either sucked or didn't work at all. Today those same kind of people write 5 programs in 5 different languages and they still don't work.

It's not hard to tell who is jumping around technologies because they are curious and who is just desperately trying to find one they can succeed at.

The only real difference I see is that today there is an amazing amount of buzzword BS to throw about in an effort to explain why their work is sub-par.

In the end, the good developers find their path. The bad ones, unfortunately, seem to disproportionately end up being your boss.

(9) This answer resonated the most with me. - Robert Harvey
(1) About bad programmers becoming your boss: Not necessarily. I'm lucky that my boss is a good programmer which means that he understands exactly what my issues are and communicates that very well to the other managers in the company. He also is able to meaningfully take part in design reviews and code reviews. Each member of the team has a monthly 1-to-1 so that any issues don't get out of hand and these conversations are actually really quite useful. However, I take your point, I too have had my share of bosses who were bad programmers or never were to start with. - Colin Mackay
(3) Those who cant manage ... - James Westgate
Dang it, can't upvote this without changing the upvote count of 64... - JavaAndCSharp
[+53] [2009-07-08 04:14:07] CaptainCasey

Absolutely. But mostly because we are taught such bad habits at university.

Nearly all these answers are provided by senior programmers. As a junior programmer I might be able to provide a different insight into this question..

At university, I was taught interfaces, patterns and software design and thought it was all rubbish. The interfaces were wasted, repeated code, the patterns nonsensical and the design felt like wasted time that could be spent programming.

This was, in a large part thanks to it being taught by computer science academics who did very little programming and often didn't understand the practicalities associated with coding.

They taught us what the material was, but not why to use it, or how. Even worse, I wasn't convinced it was even a good idea.

This is, in my understanding, very common of university graduates.

So when we get into an actual programming job and get handed that sharp knife, we wonder why you didn't just give us that bread knife, and will probably end up using the blunt side to do all the work.

For those of us who use the sharp side, it's a very steep learning curve. After 3-4 years programming badly, we have to unlearn all those bad habits as well as learn this crazy world of designing software, not hacking code.

Most university assignments are small projects, usually based on a specific algorithm or getting a specific data structure to work. Code is thrown out after submission and never reused.

In employment, a large portion of my work is changing very large existing code-bases. Code is only thrown out if it does not do the job. A poorly coded, robust solution is still a robust solution.

The very moment you first have to troubleshoot legacy code, is when you see the value in the sharp side of the knife. That moment, when you first see a class with 6k+ LOC is very much a "OH $#!^" moment.

Maintainable code is not taught at university...

(2) +1 for describing the distinction between university small one-shot programs and large code in maintenance mode. It's only in the latter that you see the benefits from the "best practices". - pjc50
(6) +1 I'm tempted to apply the "taught by academics with little practical experience, not explained what it's good for"-part to virtually my entire school experience since about 4th grade. - deceze
(2) +1 "Maintainable code is not taught at university." Because of that I'm this autumn lecturing a course about code design and TDD at my university (using material from the Clean Code book and online articles). Those things were not thought in any other courses, so there was a big hole that I felt had to be filled. Let's see how it goes... - Esko Luontola
+1 very good point, exactly how most people who courted academic life and chose the industry feel - laura
This is the exact reason why my university has a Software Engineering program that's totally separate from the Computer Science program. And I'm quite happy to be a member of the former because none of those academic problems you described in your answer seem to exist there. - Marc W
(1) +1 - I'm in the exact same boat as you, about to finish my last year of the degree. I've learnt so much more about programming languages and concepts through books/internet than at University. They don't tend to understand what they teach us. - Jamie Keeling
[+11] [2009-07-08 02:18:05] Justicle

I think the problem with patterns, especially for more inexperienced coders, is they make you think in terms of the solution, rather than the actual problem staring you in the face.

Some one, with much more experience than myself, put it nicely:

(1) +1 This blog post should be required reading for any programmer who wants to inflict his design patterns on an unsuspecting novice. - Robert Harvey
Patterns are a tool. Why blame the tool when you're using it wrong? - oɔɯǝɹ
@remco You're correct - I should blame the people who push bad tools on novices. - Justicle
(3) It's the problem with shiny new hammers -- after a while, every problem starts to feel like a thumb. - Steve Gilham
[+9] [2009-07-08 02:07:33] rado

It's useful to have all these techniques and tools, only through experience can you really be comfortable knowing which one to choose. In school they often just teach you all the syntax and things possible in a language, but give you much less guidance in using them. The frameworks, patterns, and new languages that arise in practice often give you insight into understanding how to apply the technologies.

(3) It is apparent from reading their questions that some of these programmers need a better grounding in basics before picking up the sharp knife. - Robert Harvey
How better to learn? The worst they'll do it end up with a crappy program to manage their iPod songlist. The best they'll do is learn a bit more about good programming.. right? - Blorgbeard
It's a little like giving them a map before they know how to drive a car. - Robert Harvey
After reading some books like refactoring or design patterns I felt like if had known some of those concepts earlier I would have been alot better earlier. Some other things like "premature optimization is the root of all evil" you kind of have to learn by getting burnt. - rado
I was quite proficient at reading maps long before I was old enough to drive a car. - Dave Sherohman
[+8] [2009-07-08 02:02:53] Otávio Décio

The only thing novice programmers lack IMO is the ability to choose among the various offerings and strike the best balance. Other than that I think they should go nuts and try everything with a critical eye and find their comfort zone.

Ah yes, that formal education thing. Also important.

(1) Good point. Do you think some of these programmers <cough> the TDD'ers </cough> see their tool du jour as a hammer, and every programming problem as a nail? - Robert Harvey
Beneath the TDD hype there is a lot of good ideas and practices, and if you are not aware of them yes, it is a shining hammer. If used as a design tool, I don't think there is anything wrong with TDD. - Otávio Décio
(1) Don't know that it's just TDD... I know one person who wouldn't know TDD if it bit him on the rear end, but he's got certain pet "patterns" (mostly anti-patterns) that he trots out every now and then. Just because it worked once, on an unrelated project, in a different language, ten years ago, doesn't mean it applies today. - GalacticCowboy
[+7] [2009-07-08 02:29:18] James Thompson

So long as these people aren't getting dogmatic about their approaches to programming, it's fine to explore the latest in buzzwords and see if it works for you. I like to think that this is just a giant evolutionary experiment in software engineering, and we're trying to determine what works best through trial and error. In my evolutionary analogy, programming ideas are genes, and success in software engineering is the fitness by which the genes are judged.

Sites like this facilitate horizontal gene transfer [1]. We're all just bacteria I suppose. :)


+10 for "Aren't getting dogmatic. - Robert Harvey
+1 for the evolutionary view! - oɔɯǝɹ
[+6] [2009-07-08 03:20:28] Crippledsmurf

As a young developer with no formal education myself I have experienced both sides of this coin. When I began writing code I wrote awful spagetti code with UI and logic all intertwined, not because I lacked understanding of what a class was, but because I lacked an understanding of why I should do this when it seemed to work just fine with everything inside Form1.cs.

As I became comfortable with C# as a language, I began for the first time to explore the idea of software design. I think I would be less well-rounded as a developer if I was not exposed to some of these buzzwords and design patterns that I discovered as a result.

For example, prior to hearing a Hanselminutes episode about TDD I had never even heared of unit testing; while I am aware that unit testing itself is not all that TDD is, I believe the knowlege I gained as a result of investigating it has made me a much better programmer.

To address the question directly, I believe exposing young developers such as myself to the principles of software design is essential if they are to grow into good developers. However one must not walk before he can run; there is a time in every developer's life where he must write crappy spaghetti code, if only so he has a frame of reference when considering what he has learned.

Further to this, as more experienced developers we have a responsibility to guide those less experienced; without guidance many young developers will simply cling to one pattern or methodology without the perspective necessary to understand its strengths and weaknesses.

+1 for podcasts. Aren't they the greatest thing since OOP? - Robert Harvey
@Robert Yep. Podcasys have contributed more to my learning than books of recent times. However because new zealand has steep pricing for relitivly small bandwidth quotas ($20 - $50/mo for 1GB) podcasts and windows update are a luxuary for me :( - Crippledsmurf
"more experienced developers we have a responsability to guide those less experienced". I agree, the main problem with Juniour developers is that Seniour developers generally do such a bad job of mentoring. - Martin Brown
@Martin: One's choice of mentor is obviously critical in this regard. I've never had an actual physical mentor myself, most of my interaction with people I consider mentors has been through reading their code or blogs. - Crippledsmurf
[+5] [2009-07-08 03:11:56] Esteban Araya

We should beat new programmers over the head with a copy of "Code Complete" until they learn that the number one goal when writing code is to simplify complexity. Simplify, simplify, simplify!

(2) Code Complete is a heavy book. - Nosredna
(2) I dunno, Code Complete didn't impress me that much, but maybe I need to go read it again. Personally I think the great debate on where to put your curly braces is over. - Robert Harvey
(1) @Robert: I'm currently reading Code Complete and I've found the requirements and specifications checklists and the design chapter rather useful, if brief. After five chapters it's already been worth its price, if only for helping me structure some ideas that were somehow flying around my mind. (I haven't got any forward yet because I got sucked up by Nabokov's "Pale Fire") - Daniel Daranas
I've got a stock of Java newbies that need the head-beating treatment... - JavaAndCSharp
[+3] [2009-07-08 02:23:27] mezoid

I believe that novice programmers should be made aware of them. I think that not introducing novice programmers to advanced concepts would be the biggest disservice we could do to them. They won't be experts at the advanced concepts but at least it will given them a path of study so they can grow as a programmer. They'll grow by making mistakes an being mentored by more experienced programmers. Novice programmers really shouldn't be writing code without the supervision of a senior programmer to help guide them through their mistakes. Code reviews and pair programming are great ways to accomplish this without giving novice programmers enough rope to hang themselves and the rest of the team.

[+3] [2009-07-08 02:19:05] Alan

As with most endeavors, we must seek balance.

On the one hand, our schools should teach new programmers core concepts in problem solving (divide and conquer, estimation, etc.) along with fundamentals such as sequence, alternation, repetition for imperative languages, generalization hierarchies for OO languages, and functional composition for functional languages.

On the other hand, software development is much more than collection of programming skills. Our schools should teach analysis and design, (unit, system, and integration) testing, fundamentals of networking, fundamentals of security, source code management techniques, code quality measures and more along side core.

[+2] [2009-07-08 02:21:54] hythlodayr

I understand where you're coming from. The poor novices are lead to believe they must know how to architect systems, make decisions how the team's development process, or even design important classes (or some other significant unit of code).

At best, they get a harsh dose of reality very quickly thanks to some attentive and relatively competent mentors.

At the worst, these novices become dogmatic; treating each buzzword as some sort of silver bullet; meanwhile, tried-and-true best practices known for over 30+ years are ignored and/or discarded. Look at the whole agile fiasco, for instance.

Who in their right mind actually believes the agile manifesto--which is great when understood in the proper context--means discarding things like functional specs or black box testing? Yet I recall reading many little gems like these not so long ago...

[+2] [2009-07-08 04:04:43] Joel Schlundt

What ever happened to creating the right size solution for the problem? Seriously, you should apply the right design patterns and practices when they are appropriate.

It feels more like we give people a large hammer and say every problem you see is just another nail.

[+2] [2009-07-08 03:06:30] khedron

I think design patterns are useful for two reasons:

  1. They help provide a vocabulary for communication between programmers.

  2. These concepts have been reinvented time and again. Design patterns (and architecture patterns [1]) pass along some of that historical community knowledge, giving you tips on consequences of the pattern -- what trade-offs you're making, what pitfalls you may want to avoid.


Was IOC around 20 years ago? - Robert Harvey
According to Martin Fowler, yes: For my own experience, I know of a planning system written in Lisp which supported different knowledge stores and high-level task generators. This was in a dynamic language, and so the question of "is it statically linked in or can you look it up at runtime" wasn't really relevant. I saw it used with memory systems with very different characteristics, and the planner hummed merrily along. (I assume you don't just mean "dependency inversion", in which case any language with a sort predicate counts?) - khedron
[+2] [2009-07-08 07:22:27] Michael Valenty

Working in a team environment on a large enterprise application, the most important thing to me is readability and intention.

Used properly, design patterns and unit tests tell a story. Used improperly, patterns obscure what's going on and create an even bigger mess. Sometimes I'd rather just look through a 500+ line function then trace through endless poor and leaky abstractions.

The rub is that to learn how to use a pattern correctly, you have to force it a few times. I'm certainly guilty of that.

[+2] [2009-07-08 08:16:23] Mercer Traieste

Novice programmers should used tested recipes - the alternative would be for them to reinvent the wheel.

If they get stuck on a recipe, they should ask someone more experienced.. or stackoverflow.

Once mastered, they could improve the recipe.. or invent new ones.

[+2] [2009-08-06 15:14:15] Martin

Yes, and not just young programmers. I see many people who (take ASP.Net MVC for example) want to learn the latest framework, pattern, whatever, and hammer that sucker home. Someone said this above, but the real problem is that developer's don't know that these are tools, and they need to choose the right tool for the job. There was a question on SO which asked if the developer learned MVC, what websites could he not build. Totally wrong thinking.

One site I am working on is a morph from WebForms to MVC. Is it warranted? Yes, there are NO events or need for viewstate, events, anything Webforms on the site. My problem? I am trying to implement the repository pattern, pipes and filters, and a bunch of other stuff for a project that has 2 tables and very little data.

My saving grace is that I know what I am doing is overboard, but I am doing it to learn the pattern. I learned last night this pattern was not right for me. Do I still think the repository with pipes and filters is cool, heck yea! Did it waste over 3 hours of my time last night which could have been spent finishing the project, heck yea!

[+2] [2009-08-08 08:41:14] kyoryu

The problem with design patterns, is that they don't make a whole lot of sense in procedural code. And most "OO" code is procedural code in disguise.

When you get these concepts down:

  • A method really is a message being sent, not an instruction or a command
  • Your program is not a series of instructions, but a number of objects in a particular arrangement sending messages to each other
  • Interfaces are not so much abstractions of 'things' as they are message definitions, and should generally be defined by the object that wants to send the messages
  • Most methods should be void

Then the design patterns book will make a lot of sense. Until then, it will just cause more heartache than anything.

Once you do get those concepts down, many of the patterns will just become obvious.

[+1] [2009-07-08 04:23:20] Norman Ramsey

No, I think the blogosphere gives young programmers the idea that they can and should use tools that they don't understand. At university it's our job to give students the opportunity to understand the tools they use...

[0] [2009-07-08 08:30:37] Daniel Daranas

Some people seem to think that we have been able to build good software even though our education was not perfect, but in contrast, the younger ones will be totally helpless and unable to do anything at all unless we take them by the hand and show them step by step.

I think this is not true. There are lots of smart people that will fall asleep in the middle of reading "Design Patterns" and still be able to apply them just when they are needed, not more.

Maybe some people will blindly try to use design patterns everywhere, but that's comparable, and not worse, to the horrors some people did with pointer arithmetics, ownership, bit operations and spaghetti code in C++ for decades.

[0] [2009-07-08 02:00:37] Jimmy

Generally no, because most university computer science education will have taught them the other side of the software engineering scale

[0] [2010-10-19 03:37:23] WeNeedAnswers

Got to fall down to get back up again. If they cut themselves, builds character, separates the wheat from the chaff. I would rather have someone working with me who has failed to deliver on a project at least once. I don't have to put up with the crying when the budget fails to come through, the project has been scrapped and they have spent way too many hours on throw away code. Keep it Sweet, Keep it Simple. Ship it.

[0] [2011-03-07 00:04:51] Kevin Monk

The most useful thing that you can learn in an educational environment is something that is useful to you in 10, 20 or 100 years time.

BDD, requirements gathering, user stories, OOP - These are all the things that were applicable before the first computer was even built. If I was to go back to university again, I think the acid test would be "is this going to be useful to me in 20 years?". If they want to give examples of how those things are implemented in a contemporary setting such as Cucumber for BDD then that's all fine but the emphasis should be on the idea rather than the tools.

Call me a pervert but I use Mike Cohn's "User Stories Applied" book for all sorts of projects in my life from artistic projects to life planning.