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.