Tim Lister on Project Sluts and Strawmen

cramco writes "Tim Lister, principal of Atlantic Systems Guild and co-author of 'Waltzing with Bears: Managing Software Project Risk,' and 'Peopleware: Productive Projects and Teams' talks about the patterns that help determine software success or failure. Patterns good and bad include project sluts, Brownian motion, the strawman, and the safety valve."

Comments

Isn't that basic Project Management?

[khasim]

You get the project.

You get the people for that project. You work to form them into a team that can handle that project.

You adjust the specs as the project evolves until it either dies or hits the target.

Yeah, it's a bit more complicated than that. But that's the basics. Any company that has people juggling multiple projects is going to have problems. The same with any company that forms teams without projects.

And getting together with your co-workers after work just so you can bond? Fuck that. If it happens, it happens. But do NOT try to institutionalize it. All you'll do is end up with a bunch of people waiting for the first person to leave so they can all go home to their families.

Re:Isn't that basic Project Management?

[Alpelopa]

Lister promises to provide advise on how to stop bad project management patterns and how to promote good ones within an organization. Presumably different patterns lend themselves to different techniques. If both the patterns and the techniques were obvious, bad project management would never occur. But alas, like democracy, good management is not an organizational pattern folks just fall into naturally absent impediments.

It would also appear from the interview snippet that the authors plan to use a patterns book to argue for agile management approaches as a way to minimize risk. Slashdot readers may be sold on this idea, but in my experience, most business managers instinctively see the waterfall method as the least risk path whether they admit it or not. A few more ideas for how to change that perception could be useful.

That said, I whole-heartedly agree with you on the bonding after work bit. The bonding and "blowing off steam" examples seem to assume no one on your project team is ever going to be over 21.

Missed the Gang Bang pattern

[Anonymous Coward]

Similar to the project slut pattern, but instead of saying "yes" to each project, multiple projects are forced on you, whether you can take it or not. Can lead to many "dead fish" projects (and bad jokes dealing with fish and fish smell).

strawman

[KillerCow]

One of the best is strawman: building low-fidelity, low-cost prototypes for projects even if you know the approach isn't right.

Yes, it's an awesome idea until some PHB doesn't realize that software development is like and iceburg and forces dev to use the prototype as the production version.

"But, it looks 90% done!"

Re:strawman

[SpaghettiPattern]

quit rather than take the responsability behind that...
I know what you mean. However, my experience is that doing the contrary and to NOT code until everything is documented and blessed by everyone is the wrong way to do it. In large organisations (which where I work mostly), before the documentation is finished a couple of project leaders have come and gone. The GO AHEAD AND CODE is given in despair, the concepts in the docs are overtaken by evolution and the bright people have left.

I am willing to take on a bit more responsibility to have more fun at my work. Having said that, I live in Europe and over here things like responsibility/liability are taken differently than in the US.

"dead fish" reinvents Yourdon's "Death March"

[pg--az]

[["We also see a pattern called dead fish. This is a project that is doomed from the start because the schedule is outrageously unrealistic."]]
Checking Amazon, Edward Yourdon's "Death March, Second Edition" was released in 2003, I had not realized there was a second edition: "...companies continue to create death-march projects, repeatedly! What's worse is the amount of rational, intelligent people who sign up for a death-march project - projects whose schedules, estimations, budgets, and resources are so constrained or skewed that participants can hardly survive, much less succeed."

Re:"dead fish" reinvents Yourdon's "Death March"

[dr.g]

The very worst thing about "dead fish" and "death march" projects is how easy it is for ANYONE to label the Bringer of Bad News (i.e.: he who points out the hard, cold realities) a NEGATIVE INFLUENCE. This then reinforces the more cynical attitude of just shutting up and letting shite hit fan, especially if by doing so, OTHER PEOPLE will be splattered with said shite. Sad that by this, one becomes known as a "team player". Bleh.

Not surprised by /. reaction thus far

[stewbacca]

Why am I not surprised that a bunch of slashdot nerds are on the defensive just because a project manager points out a couple of common project problems? One of the main problems in any project is when the low-man-on-the-totem-pole thinks he knows better than the manager. That's exactly what this discussion thread has turned into so far.

Re:Not surprised by /. reaction thus far

[stewbacca]

Good point. But you have to admit, some of these replies are because the people are replying are guilty of nearly everything wrong with what the article talks about. Deep down, I think they know it too, thus they lash out against an otherwise interesting article. I'll be looking into the book for sure.

Yes and no

[Moraelin]

Well, yes and no. Probably most people have some intuition the basics, but:

1. Some people are just incapable of implementing them, or can't be arsed.

2. Some people are operating in a brain-dead rules zone.

E.g., it's easy to say "hiring lots of people before you know what you'll use them for is wrong" (what he calls "brownian motion"), but sometimes lobotomized corporate rules twist one's arm to do exactly that. It could be that you have a fixed time window to do the hiring, or the ever popular "if we don't use this year's budget fully, we'll get a budget cut next year", etc. You'd be surprised how many anti-patterns are really just work-arounds for rules that sounded good on paper, to someone who's (A) not qualified to take that kind of decisions, (B) bored enough to take them anyway, or a new boss pissing on everything to mark his territory, (C) way too far disconnected from the data to base those decisions on, (for example by being several hierarchy levels too high, or in a whole different brach of the hierarchy altogether, and having no communication level to the people who actually know what's happening there), and (D) shielded from the effect of bad decisions (e.g., if there are any good results it's his merit, if it goes south fast, it's the fault of the henchman who had to implement them.)

Heck, you've given a very good example yourself. Even good ideas can be turned into bad and annoying rules, and there are a lot of places where exactly that happens. Bonding between people can be a good idea, and it can even be helped along a bit (but it's hard and most people don't have the necessary skills.) But then department A comes with a rule that says "thou shalt meet with your team mates at a pub once a week" (more often is always better, right?), department B comes and says, "but thou shalt do it on their free time, because we're not paying you lot to sit around and chat", department C comes and says, "and we're not paying for it", a boss change comes at department A and says, "nah, thou shalt use a meeting room, it's cheaper", and boss D come and says, "cool, I'll come along and motivate people with a speech. What could be more bonding and motivational than everyone hearing how great I am, and how any good results are due to my enlightened leadership?" What started as a good idea, was turned into the perfect recipe for a morale disaster.

(And, sadly, the above paragraph isn't made up. I know one place where exactly that setup was institutionalized.)

3. Some people operate on bogus data, and often are deliberately fed bogus data, for example by some underling who has something to gain from forcing a bad decision.

E.g., manager X figures out he'd get a promotion if he got just 5 more people under him (usually again a case of brain dead rules), so he'll actually support anything that makes it look like his project needs more people. Or will actively argue for "brownian motion" kind of arguing.

E.g., I've actually seen one sad case where someone sabotaged his own project just to show everyone that Java sucks, unlike his beloved VB. The guy not only couldn't be arsed to actually manage that project, and spent 90% of his time trying to manipulate unrelated non-technical managers (this wasn't a software house but a manufacturing corporation with an IT department) into seeing it all as "that's the kind of extra complexity Java produces), but actively changed specs or introduced random new requirements when the project looked like it was getting anywhere.

4. Some are just dishonest fucks, and just follow their own goals, which aren't the same as the company's goals. E.g., the guys mentioned at the previous point.

5. Some actually know what should be done, but don't have the spine or the authority to counter client aikido maneuvers.

E.g., saying "you should first make a disposable low-cost prototype" is good and fine. But I can tell you first hand that in a lot of cases the client has no clue what's the difference between a HTML prototype and a full

Re:Yes and no

[psmears]

E.g., saying "you should first make a disposable low-cost prototype" is good and fine. But I can tell you first hand that in a lot of cases the client has no clue what's the difference between a HTML prototype and a full working program. A lot (most?) non-technical clients think the hard part is placing the buttons or getting the colours right, so if the prototype looked right, that must be almost ready as the application goes.

Very true—non-technical people judge how ready your application is and how well it is built by how pretty it looks. A useful technique for dealing with this problem is to turn it to your advantage: for your prototype, make sure it is as ugly as possible while still achieving its aims (e.g. mismatched fonts, badly aligned fields, poorly chosen colours, blocky graphics etc). With luck, your customers will agree that it sort of does the right thing, but couldn't possibly be used as a basis for future work. For your beta, tidy up the formatting and get it about right, but leave the graphics and colours still looking patchy. Then for the final release, make sure everything looks slick and pixel-perfect.

This (sadly) can be a much more effective way of managing people's expectations than repeatedly telling them, "This is only a prototype and doesn't really work..."

Re:Most Programming is not an art

[NeuralAbyss]

Software engineering is not art as a whole, but there are facets where the decomposition and implementation of a software system can be viewed as an artform. Personally, my view is that it is seen as an art not only because of the creative aspect of programming (algorithm design or selection), but also due to the lack of maturity of the software engineering industry.

Industries such as Civil Engineering have had centuries of refinement, whereas the SE industry is relatively young, only really developing in the last half-century. We haven't had the same amount of time to derive generic methods to decompose systems, and as a whole, the industry acts as a set of disconnected islands - predominantly, not sharing information or practices.

In the last couple of decades, there have been forward strides made with regards to identifying patterns and other generic, reusable software engineering assets, but the overall industry is still immature. In addition, the diversity of projects leads to a higher degree of perceived (and perhaps, actual) complexity - to take a Civil Eng analogy, one day we (Software Engineers) are building bridges, the next we'll be building a space elevator, and the day after, constructing a skyscraper.

My personal belief is that it's a matter of time before software engineering as an industry matures, and before that occurs, the degree of sharing and derivation of generic, reusable software components needs to increase rapidly.