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."
The whore my book pattern.
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.
Let me tell you, nothing motivates me more at work than a project groupie who will bang me for completing on time.
What do you mean not that type of slut?
I still have more fans than freaks. WTF is wrong with you people?
FTFA...
... I'd like people to think about patterns - abstracting their work and recognizing the patterns they're in, good and bad, and making informed decisions to promote those patterns or replace them.
Lister: I get chills when I hear that phrase. From my point of view there are some pretty good practices, but no best practices
So, Lister... would thinking about patterns be a best practice?
Uh-oh! the chain of logic has been attached to itself, we're trapped in a circle from which there is no escape!!
The whore my karma pattern.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
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.
Obviously, you hold their families hostage at an undisclosed location until the conclusion of the bonding is complete.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
I had to quit a job because of that. My boss kept asking me to make prototypes to prove concepts, which I did...then ask me to build entire ERP and CRM systems around the prototypes, which obviously was impossible within the constraints given, and definately impossible to keep maintainable, and mostly secure (they were web based systems exposed to the net, and the prototypes were not security aware...). I quit rather than take the responsability behind that...
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.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
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.