Bad Design Patterns

I've identified a design pattern that is lousy.  The pattern only indirectly has to do with software though.  This is a pattern that management tends to use and model their efforts on.  The Firefighter Pattern.  Fair warning this blog entry contains ranting and raving.  I will go off topic and complain. 

The Firefighter Design Pattern this one I'm sure everyone will recognize, it basically has to do with everybody scrambling to put out a fire.  Now by a Fire I don't mean a literal “the barn is burning down“ fire;  what I really mean to say is there's some work based emergency.  Maybe a critical bug is found, or a client is down and can't utilize their app.  These would be acceptable “fires“ to put out using the Firefighter design pattern.  The problem I have with this pattern is when its used as the primary design pattern, when there's nothing else that's really done.  You just go from one fire to another then to another in an attempt of putting all of them out.  The biggest problem here is there's no way to schedule your resources or even sometimes to plan your day.  Another major problem with this is it quickly runs into the boy who cried wolf.  If there are too many “fires“ you'll quickly find that when a real one pops up you can't fight it.  Maybe this is just a symptom of the cost cutting that we've all seen in this economic period (which is slowly getting better).  Is it that companies are just so strapped to  keep costs manageable that they resort to these tactics in a last gasp effort to make it all work?  Although that's would probably be the most common answer (if a survey was taken) it doesn't seem to make sense.  By scheduling and intelligently distributing work you stand a much better chance of producing a lot more with a lot less.  I also think that people fall into this pattern when there's a lack of information and communication.  If you're completely kept in the dark about things, you often won't know enough to object to things being done in a less than optimal manner.  If you've got good communication you can often solve problems quickly and more efficiently.  I think a lot of us know that though, and that point will really not reach who it's meant to.  Many here on weblogs.asp.net also use the forums and the aspadvice mailing lists, we know that if we're having a problem we can reach out to each other to get help.  I'm getting off topic or rather off rant.  So here's my question; what do you when the process breaks down?  What happens when there's very little communication?  Now I've been on a couple sides of this issue.  I had the displeasure of working for a team that did not get along well and management wouldn't communicate with; this didn't work for me and I moved on after a few months (the team ultimately finished their tasks almost a full year late).  I've also been (and currently am on) a team that gets along very well, but still there's no communication from the management side and we're largely in the dark.  Now it is not my intent to disparrage or attack people in management positions.  There are a lot of managers that are far smarter and more skilled at their craft than I am at mine. 

I personally believe that very few problems ever fall on the shoulders of one group or type.  The blame can almost always be spread around.  I believe I am at fault here too.  Its as much my fault for allowing the situation to continue as is.  I unsure however what to do about it.  It seems complaining and acting like a squeaky wheel is not as effective as it was when in kindergarten.  (Although there are reports of some having great success with it their whole careers -- but that's another rant for another day)  It just gets tiring.  If anyone has had some good or even moderate success facilitating better communication in their organization from a developer or non management level, please post a reply and share how you did it.  Ok that's my $.02 for the day.  I'll blog about something cooler next time.

Comments

# Andrew said:

There seems to be nothing in the fire drill anti-pattern ;)

http://c2.com/cgi/wiki?AntiPatternsCatalog

Tuesday, December 02, 2003 2:47 PM
# Darrell said:

The reason management-types like the firefighter pattern is that it absolves them of responsibility. If you always handle "urgent" business, nobody can say you aren't doing your job. If the developers can't put out the fires quick enough, they are the ones to blame, not the manager who could not prioritize.

This is exactly what Stephen Covey wrote in "The 7 Habits of Highly Effective People." If you use this pattern, you have to run faster and faster just to stay in the same place, until you eventually get tired and fail.

Johanna Rothman also posted something about this yesterday, "The Manager's First Role: Prioritization." (http://www.jrothman.com/weblog/archive/2003_12_01_mpdarchive.html#107031900607198306) She says basically the same thing.

Amazing that there is all this literature out there on why this pattern of behavior is bad and prioritization is good, but nobody does it. I forget who said this, but it is so true, "To learn from your own mistakes is experience. To learn from the mistakes of others is wisdom."

Tuesday, December 02, 2003 2:57 PM
# Scott Sargent said:

Sadly you're right, Its frightening to think of what the software I develop would look like if I did just enough to get by. I've always wanted to excel at my job, and I truly believe that I do. I've never read the 7 Habits of highly effective people, but a similar book by Richard Marcinko has some similar themes: (http://www.amazon.com/exec/obidos/ASIN/0671545140/inktomi-bkasin-20/ref%3Dnosim/102-1152837-6403343) Really good stuff, i like to re-read it every so often just to confirm and reinforce the lessons.

Tuesday, December 02, 2003 3:08 PM
# Kristopher Cargile said:

In many professional disciplines --programming, architecture, design, and so on -- design patternsoften...

Wednesday, August 23, 2006 1:02 PM
# Patterns of Failure - bettersoftwarenow.com said:

Pingback from  Patterns of Failure - bettersoftwarenow.com

Saturday, August 16, 2008 6:09 PM

Leave a Comment

(required) 
(required) 
(optional)
(required)