Comments on: The 5 dysfunctions of teams in code http://www.markhneedham.com/blog/2009/05/28/the-5-dysfunctions-of-teams-in-code/ Thoughts on Software Development Sat, 11 Feb 2012 23:17:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Hendry Betts http://www.markhneedham.com/blog/2009/05/28/the-5-dysfunctions-of-teams-in-code/comment-page-1/#comment-19077 Hendry Betts Tue, 23 Jun 2009 14:34:10 +0000 http://www.markhneedham.com/blog/?p=1258#comment-19077 Mark, What a GREAT POST! Thank you. But I have to raise a point about fear of conflict. That is a management issue. If ideas are not encouraged and passionate discussion not fostered (by management) then there is no knowledge of how to get an idea "on the floor." I love the rest of this article and agree that bad code directly relates to bad teams... but more importantly, bad management. Mark,

What a GREAT POST! Thank you. But I have to raise a point about fear of conflict. That is a management issue. If ideas are not encouraged and passionate discussion not fostered (by management) then there is no knowledge of how to get an idea “on the floor.”

I love the rest of this article and agree that bad code directly relates to bad teams… but more importantly, bad management.

]]> By: Rob Myers http://www.markhneedham.com/blog/2009/05/28/the-5-dysfunctions-of-teams-in-code/comment-page-1/#comment-17799 Rob Myers Thu, 28 May 2009 20:08:17 +0000 http://www.markhneedham.com/blog/?p=1258#comment-17799 As I read this, I thought of Fowler's/Beck's code "smells," and also Steve McConnell's good code attributes (cohesion, appropriate coupling, no duplication, good encapsulation...) from his book, _Code Complete_. You've mapped code dysfunctions to the human drivers (confusions or dysfunctions) that produce such code. Very nice! I'll be pointing to this a lot. Thanks! As I read this, I thought of Fowler’s/Beck’s code “smells,” and also Steve McConnell’s good code attributes (cohesion, appropriate coupling, no duplication, good encapsulation…) from his book, _Code Complete_.

You’ve mapped code dysfunctions to the human drivers (confusions or dysfunctions) that produce such code.

Very nice! I’ll be pointing to this a lot. Thanks!

]]> By: Gerald Weinberg http://www.markhneedham.com/blog/2009/05/28/the-5-dysfunctions-of-teams-in-code/comment-page-1/#comment-17788 Gerald Weinberg Thu, 28 May 2009 15:44:10 +0000 http://www.markhneedham.com/blog/?p=1258#comment-17788 I love the way you illustrate "people problems" (and, particularly, "team problems") with code symptoms. It's definitely a major tool in my consulting tool-kit: "Look at code and ask youself, 'how did it happen to come out this way?'" I want to pick a nit with you statement about "code that has been written in such a way that only the person who wrote it is really able to understand it." There's a dangerous assumption there, that the person who wrote such code actually understands it. It's an assumption that's more often false than true. Overly complex code that nobody but the writer has ever reviewed is extremely likely to be wrong. Indeed, for several reasons, it's more likely to be wrong than code that's produced in full cooperation with the team. I'm sure you know this, but it's easy to forget in the heat of the battle with the person who won't let others see what s/he's doing. So, when someone claims to be the only one who understands the code they wrote, get rid of the code, then get rid of the person who wrote it. I love the way you illustrate “people problems” (and, particularly, “team problems”) with code symptoms. It’s definitely a major tool in my consulting tool-kit: “Look at code and ask youself, ‘how did it happen to come out this way?’”

I want to pick a nit with you statement about “code that has been written in such a way that only the person who wrote it is really able to understand it.” There’s a dangerous assumption there, that the person who wrote such code actually understands it. It’s an assumption that’s more often false than true.

Overly complex code that nobody but the writer has ever reviewed is extremely likely to be wrong. Indeed, for several reasons, it’s more likely to be wrong than code that’s produced in full cooperation with the team. I’m sure you know this, but it’s easy to forget in the heat of the battle with the person who won’t let others see what s/he’s doing.

So, when someone claims to be the only one who understands the code they wrote, get rid of the code, then get rid of the person who wrote it.

]]> By: Andy Palmer http://www.markhneedham.com/blog/2009/05/28/the-5-dysfunctions-of-teams-in-code/comment-page-1/#comment-17783 Andy Palmer Thu, 28 May 2009 13:37:51 +0000 http://www.markhneedham.com/blog/?p=1258#comment-17783 Your point of Absence of Trust was where I was coming from with '<a href="http://andypalmer.com/2008/08/returning-null-considered-dishonest/" rel="nofollow">Returning null considered dishonest</a>'. Null checks are a symptom of the fact that you can't trust that you'll get back what you want. I asked for a Drink and you gave me a null! Your point of Absence of Trust was where I was coming from with ‘Returning null considered dishonest‘.
Null checks are a symptom of the fact that you can’t trust that you’ll get back what you want.
I asked for a Drink and you gave me a null!

]]> By: Andy Marks http://www.markhneedham.com/blog/2009/05/28/the-5-dysfunctions-of-teams-in-code/comment-page-1/#comment-17747 Andy Marks Wed, 27 May 2009 20:46:47 +0000 http://www.markhneedham.com/blog/?p=1258#comment-17747 Hiya Mark, I too have recently read the book and loved it for the accessible tone and brevity. Kudos for making the connection to coding. Given the definitions of the dysfunctions above, I might re-cast a couple slightly: - Lack of commitment. Some people in team not using agreed upon patterns or layers when coding. Or not refactoring towards agreed technical vision - Avoidance of accountability. When the team doesn't call out (name and shame, if you will) devs who commit code without tests. Cheers, Andy Hiya Mark,

I too have recently read the book and loved it for the accessible tone and brevity. Kudos for making the connection to coding.

Given the definitions of the dysfunctions above, I might re-cast a couple slightly:

- Lack of commitment. Some people in team not using agreed upon patterns or layers when coding. Or not refactoring towards agreed technical vision

- Avoidance of accountability. When the team doesn’t call out (name and shame, if you will) devs who commit code without tests.

Cheers,
Andy

]]>