Ward Cunningham of Microsoft's Patterns and Practices group discusses the importance of patterns as a means to capture knowledge and experience as well as how the patterns movement got started. He also talks about XP and how the social interaction of paired programming leads to better code.

Architecture is so important that everybody has to have it in mind all the time and to think that we can take the responsibility for good architecture and concentrate it in one individual is the real mistake.

Ward discusses how patterns come about and how we begin to recognize them in our own work.

The nice thing about a pattern is you take that something everybody knows how to do and you give it a name; and a lot of people look at it and say “I knew how to do that only I never called it that.”

He also talks about the problems with the lone developer paradigm and why the social interaction of paired programming in XP allows for a faster communication between developers. He further shows how this communication is similar to defining a pattern.

I do know that a lot of times if the programmer gets good; while he is getting good, he learns that most people do not understand what he does. So that’s really separating for programmers. Programmers are kind of driven apart by that realization that they are dealing with things that most people do not understand and after a while they give up trying to communicate.

Watch the entire interview with Ward Cunningham.

I am sooooooo glad that they aprove.

I was a bit insecure before MS blessed paterns and was not sure if I should quote GoF to anyone. Everyone, out of the closet!

.V

nice comments vic :-)

i have to disagree with the whole paired programming, it might just be our company, but I can't see it being very efficient. Look at how Agile development works, where code and requirements can and are constantly changing, how is two sets of eyes versus one set going to make the code any better given the current state of development on an agile project? If you are opening your code for other suggestions, why not do it at the end with everyone with peer code reviews?

Any thoughts?

I found pair programming to be very effective, so long as it wasn't taken to religious extremes ('Every line of code must be pair programmed'). On the pair programming project I did, all of the developers understood every aspect of the system, and there was no piece of code that some developers were afraid to touch. Group adherence to design and coding standards was higher on that project than on any other I have worked on.

If you are opening your code for other suggestions, why not do it at the end with everyone with peer code reviews?

1) Because we are imperfect people. When we put off activities like testing and code review until the end of development, they tend not to get done, or to be done rather poorly. What I've always liked about XP is that it integrates these activities naturally into the development process.

2) I found that I grew more as a developer during the pair programming project I did than any other. The kind of practical design strategy discussions where you learn most were occuring every day, rather than at a biweekly, poorly attended, hourlong group meeting.

Let me put it this way:
I think MS developers should use XP methodlogy, what w/ anecodtal requirments.

I use "pair monitors" per developer variation, ie dual monitors, one displays IDE the other container console.

http://www.softwarereality.com/ExtremeProgramming.jsp

.V

i have to disagree with the whole paired programming, it might just be our company, but I can't see it being very efficient. Look at how Agile development works, where code and requirements can and are constantly changing, how is two sets of eyes versus one set going to make the code any better given the current state of development on an agile project? If you are opening your code for other suggestions, why not do it at the end with everyone with peer code reviews?Any thoughts?

We've found pair programming to be essential in a large long running project because:

- fewer mistakes are made up front because there are more eyes on the problems
- it's the best way to get people up to speed on how the project works
- it's the best way to reinforce how the project works (i.e. no-one goes off and develops something that looks nothing like the rest of the project)
- if someone leaves they don't take all that knowledge with them
- if someone goes on holiday they don't take all that knowledge with them
- if someone leaves early to look after their sick puppy they don't take all the knowledge with them
- code reviews are done on code where all the design decisions have been made, pair programming helps get that design correct up front. a code review may find bugs and really bad design but often mediocre design is left alone for pragmatic reasons. that said, code reviews are still useful.
- pair programming is less costly than you think (consider the cost of a production defect, if your organisation is of any reasonable size, this means: annoyed customers, stoppages, new development, testing, deployment etc.)

We've found pair programming to be essential in a large long running project because.....

Does the same apply for maintenance cycles?

I have been wondering for some time what was up with patterns: they were all around in the late '90s and that resulted in some valuable books. Recently the major books that I'm aware of have been Patterns of Enterprise Architecture, Integration Patterns, Core J2EE Patterns maybe.
I must admit I don't follow the Patterns part of TSS or Ward's Wiki but I do wonder if there have been some catalogueing efforts that resulted in books.
A lot of the discussion of patterns turns back to the GoF book. Surely the well of patterns has not dried up since then.
Have I missed something?

Oh, btw: I'm one of those who has reservation about the efficiency of pair-programming. Now that MS is hiring XP-men like Cunningham & Fowler it will be interesting to see wether MS will choose pair-programming in a big way or that pair-programming recedes in the background when it hits the harsh reality of large-scale commercial software development...

groetjes,
Joost

I am sooooooo glad that they aprove.I was a bit insecure before MS blessed paterns and was not sure if I should quote GoF to anyone. Everyone, out of the closet!.V

Yeah. We need now only Miguel de Icaza to take back that 'Academic crap' statement and we can sleep well as being on the right track ! :-) booh !

When I switched from C++ to Java, I found that many of the slick tricks I'd learned in order to implement patterns in C++ are inherent in the design of the Java language. A case in point is the class loader, and the way it allows bean factories that far surpass anything C++ can do out of the box.

I'm not the only one. When Doug Schmidt's ACE platform was converted from C++ to Java, half of the code was eliminated because it's taken care of by the Java platform.

Patterns are not a movement, they're a religion!

ACE: http://www.cs.wustl.edu/~schmidt/ACE.html

regards,
Roger Hoppe

"Now it's kind of funny that they give me a title of Architect because I spent so many years trying to explain why we don't need them and now I are one."

Not funny, more like a bit hypocritical.

"Programmers are kind of driven apart by that realization that they are dealing with things that most people do not understand, and after a while they give up trying to communicate."

Perhaps Cunningham is kind of driven apart and gives up trying to communicate, but I don't find this to be true of most developers. On average developers love to communicate. If it all boils down to having someone sit next to me and say "Here, and Here', "Like That", or "Do that again" then we're better off with a looped mp3 of Ward.

The interviewer asked about the cost of change curve, and I was a disappointed that he didn't dig further into perhaps how that turned out in C3...it's been 5 or so years, I wonder how maintainable the C3 code is after being constantly used and refactored after all this time.

Taylor

<blockquoteThe interviewer asked about the cost of change curve, and I was a disappointed that he didn't dig further into perhaps how that turned out in C3...it's been 5 or so years, I wonder how maintainable the C3 code is after being constantly used and refactored after all this time.TaylorIIRC, the C3 project was canned and never went live. I don't remember the references.

"Now it's kind of funny that they give me a title of Architect because I spent so many years trying to explain why we don't need them and now I are one."

Not funny, more like a bit hypocritical."

Please listen to or read the ENTIRE interview before you start mud slinging!

Later in the interview, Ward Cunningham : "What I really mean is we don't want to excuse all developers from being architects. Architecture is so important that everybody has to have it in mind all the time, and to think that we can take the responsibility for good architecture and concentrate it in one individual is the real mistake."

"Now it's kind of funny that they give me a title of Architect because I spent so many years trying to explain why we don't need them and now I are one."Not funny, more like a bit hypocritical."

Please listen to or read the ENTIRE interview before you start mud slinging!Later in the interview, Ward Cunningham : "What I really mean is we don't want to excuse all developers from being architects. Architecture is so important that everybody has to have it in mind all the time, and to think that we can take the responsibility for good architecture and concentrate it in one individual is the real mistake."

the bane of all good developers is the lazy ones who short cut and do a crappy job. they are every where in every industry. although I wish there are fewer crappy developers, I must say it's going to stay roughly the same. they only way to avoid it is to find good companies to work for.

Patterns and pair programming are good but upto a certain extent. I mean two programmers can discuss with each other how to implement a specific set of problems in pusedo code but sitting and writing code together is waste of money and time; and above all it kills your creativity, the best trait we got as a programmer.

I am kind of against the heavy use of design patterns; first and the most becuase it makes your code very hard to understand, and ultimatley (it is ironic) so hard to maintain.

Besides that I saw people very narrow minded about the patterns taught by their masters:-),these patterns may have some valid use in some context, but it also confine programmers brain to just think in one direction.

All I want to say against patters is God damn it we are programmers "We don't need no education We don't need no thought control"

Hi Rashid,

I am kind of against the heavy use of design patterns; first and the most becuase it makes your code very hard to understand, and ultimatley (it is ironic) so hard to maintain.

Heavy use of anything is usually a bad thing. While I would agree that some patterns add complexity, they typically do so for added flexibility. Your job as a developer is to determine when this trade off makes sense. I haven't found patterns to yield code that is difficult to maintain when applied properly. Actually, I have found the direct opposite.

Besides that I saw people very narrow minded about the patterns taught by their masters:-),these patterns may have some valid use in some context, but it also confine programmers brain to just think in one direction.

This is a typical mindset in my experience as well and is probably the single biggest reason patterns often get a bad rap. Patterns are almost never helpful when used as simple cookbooks because they are really general solutions to a common set of problems. Patterns require some thinking on the developer's part to apply correctly because they must often be adapted to the specific problem at hand.

All I want to say against patters is God damn it we are programmers "We don't need no education We don't need no thought control"

You sound like someone who doesn't really understand the value of patterns (or even how to use them properly). I'm not saying that to cause a stir - just trying to be honest. Patterns help us capture hard won (and time-tested) experience from others in the industry. I think you are being short-sighted by snubbing your nose at this valuable experience. Use them when appropriate and they can be one of your biggest tools in the chest. They can also be a great aid for spurring your own creativity, so give these little fellas another chance (preferrably from an experienced practitioner who can show you the ropes)...

So in summary, patterns can (when used properly):
 - Simplify code.
 - Make code more flexibile (sometimes at the cost of additional complexity).
 - Make code more resilient to change.
 - Save you from reinventing a perfectly reusable wheel.
 - Help identify bad practices and serve as targets for refactoring
 - Spur your creativity during the design process (whether on paper or in your head while coding/refactoring).

The downside is that patterns are often misused because they require one to think before using. Most developers prefer to hack first and ask questions later. ;-)

Respectfully,
Bill Willis

You sound like someone who doesn't really understand the value of patterns (or even how to use them properly).

Thanks for the complimants Bill...

After so many years the only concrete lesson that I tout to undersatnd with out the subjective cloud of fuzziness is high cohesion and low coupling. After so many years again back then the GOF gave me a very valuable lesson that stood tall even after so much time has been passed; program to an interface not implementation, avoid implementation inheritence, and reusability in terms of composition over inheritence. My friend these concepts are the biggest tools in the chest of any programmer, trust me, much bigger than the 23 patterns every architect try to squeeze in his/her project.

I thought the most meaningful book in OOD I've ever read (and I've read pretty much everything for pattern/architecture books) is Agile Software Development by Robert C. Martin. This book doesn't talk patterns, it talks principals, everything else you read is just fluff ;-)

This book doesn't talk patterns, it talks principals, everything else you read is just fluff ;-)

Thanks Jacob, that was exactly my point.

Thanks for the complimants Bill... After so many years the only concrete lesson that I tout to undersatnd with out the subjective cloud of fuzziness is high cohesion and low coupling. After so many years again back then the GOF gave me a very valuable lesson that stood tall even after so much time has been passed; program to an interface not implementation, avoid implementation inheritence, and reusability in terms of composition over inheritence. My friend these concepts are the biggest tools in the chest of any programmer, trust me, much bigger than the 23 patterns every architect try to squeeze in his/her project.

Sorry for my bluntness earlier. Many of the GoF patterns are actually founded on those principles (and others). Furthermore, they provide concrete lessons in how those principles can be combined and applied to improve software design. It is no surprise that principles lay the foundation while patterns build on them to provide common design solutions. I wish you had gotten more out of patterns - too bad really...

I just posted a bit on the subject on my blog:

http://hookom.blogspot.com/

I also have found that it is enough to discuss ideas and solutions in pairs or small groups and come up with a plan for every developer. There can be occasional 'consulting' to solve mini-problems but not every line of code has to be googled by two people.

And lets not forget that paired programming creates managements perfect "flexible workforce".

"What do you mean you wont work for 30K less? You're only doing the same job as that graduate we paired you with last year and he works for peanuts!"

Know any 'paired lawyers', 'paired doctors' or 'paired accountants'?

Know any 'paired lawyers', 'paired doctors' or 'paired accountants'?

Actually, according to an article in the New Yorker some months ago, doctors in hospital often work in pairs. As soon as one doctor has mastered a certain technique, he doesn't practice it, but rather teaches and supervises other doctors in that technique. This matches at least the 'spread the knowledge around' aspect of pair programming.

And of course lawyers like to work in droves, though this has more to do with billing and evading responsibility than with getting any work done.

Certified public accountants also often work in pair, so that they do not make mistakes in verification of digits and in any significant accounting judgement.

It seems natural to me that any intellectual human activities involve close interactions.

Certified public accountants also often work in pair, so that they do not make mistakes in verification of digits and in any significant accounting judgement. It seems natural to me that any intellectual human activities involve close interactions.

Please don't compare accoutants and lawyers with programmers. We are more closer to an artist, as a matter of fact programming is an art. Have you ever seen two painters painting "Mona Lisa".

On man that is funny. As much as I like to think programming is a creative process, it isn't quite like painting the Mona Lisa. What happens when someone with multiple personality disorder paints a picture? Does that count as pair programming :)

Please don't compare accoutants and lawyers with programmers. We are more closer to an artist, as a matter of fact programming is an art. Have you ever seen two painters painting "Mona Lisa".

How about thinking this way.
Have you never been in a situation where you are working in a team and one of your teammate is writing a terrible piece of code? You might have hesitated to bother him because pointing out the inelegance of other person's code is itself inelegant.

If your team is pair-programming, you can act against the situation without becoming inelegant.
Off course, you have to be understood and accepted by other people if you want to influence their code. But artists have to try to be understood by public, anyway. :-)


Cheers,

Architecture is so important that everybody has to have it in mind all the time and to think that we can take the responsibility for good architecture and concentrate it in one individual is the real mistake.

Doh!!!