Thursday Jul 12, 2007

Project Sluts

In an interview with businessofsoftware.org, Tim Lister defined three software project anti-patterns that are interesting if for no other reason than that they have colorful names.

A Project Slut is an organization that takes on too many projects ("it just can't say no" he says). The result is that nothing gets done, or nothing gets done well. I can say as a developer that this has a negative effect on team moral. The feeling that everything is a hack or quick fix and rushed out the door to users is not a good one. It's hard to take pride in your work. There's a lot to be said for picking fewer things and doing them well. Developer's productivity is in proportion to their pride in what they are doing. If they don't feel good about it, it's much less likely you'll see them there after hours making sure it's done well.

A Brownian Project is one has too many people added too early on. For example, the project might have too many people involved at the design phase such that the design progresses slowly as a result of trying to incorporate the ideas of everyone involved ... or worse, you end up with what I'd call a "compromise design". A compromise design sacrifices coherence to appease the people involved in the design. This is often the case with specifications that are designed by a committee of interested software development corporations.

Notice that I said "corporations". I am reminded of the JDO2 specification, which was controversial in it's time because it had overlap with an up and coming specification we now call EJB3. Reading the official "votes" from various companies, many were against it. Nevertheless, Sun pushed it through adding to later confusion of many users when JPA came to the scene. I'll never forget the Apache Software Foundation's comment though: "Let a thousand flowers bloom" (a yes vote).

A Dead Fish project is one that sets an unrealistic date, or impossible requirements, etc., and therefore is doomed to fail. This doesn't strike me as a useful pattern, or a pattern at all. A pattern is something you can use to help you solve a problem. No one starts a project with the foreknowledge that it's going to fail. Pick any project, and you can find at least someone that thinks it's going to fail, and someone that thinks it will succeed. This pattern can only be applied in hindsight, which makes useless.

About

jtb

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today