Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Tim Lister on Project Sluts and Strawmen 128

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."
This discussion has been archived. No new comments can be posted.

Tim Lister on Project Sluts and Strawmen

Comments Filter:
  • by NeuralAbyss ( 12335 ) on Thursday July 12, 2007 @08:59PM (#19844713) Homepage
    Looks like yet another slashvertisment for an upcoming book/conference.

    It's a nice start, but lacking any real depth - the article could be summarised in one or two sentences, listing a number of good and bad practices. I know it's stripping people of their $DEITY-given right to derive fiduciary advantage from relaying information and opinion, but can we please have some /real/ in-depth software engineering articles for once in a while?
  • Re:strawman (Score:5, Interesting)

    by Shados ( 741919 ) on Thursday July 12, 2007 @10:18PM (#19845151)
    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...
  • Re:strawman (Score:2, Interesting)

    by fractoid ( 1076465 ) on Thursday July 12, 2007 @10:21PM (#19845157) Homepage
    Oh god, don't remind me. That is, in my mind, the biggest weakness of rapid prototyping. You get an interface, sometimes a whole product mocked up to "is that how you like it, mr beeblebrox?" level, and suddenly your boss / project manager / client is thinking "wow, it's nearly finished!" followed by the inevitable "well, that works, let's just use that!"

    And then they blame you when they realise that the prototype is actually a flaky piece of s#!t because all it was designed to do was pretend to be the product they wanted. Gah!
  • by Repossessed ( 1117929 ) on Thursday July 12, 2007 @10:40PM (#19845233)
    I've seen organized get together work pretty well actually, It's all about how you go about doing it. Do *not* make it mandatory, or even suggest that it should be. Instead offer a non-work related incentive for people to come. (Free pizza/beer/bowling alley fees, or whatever will be attractive to your team). The people who want to show up to an event do so, the people who don't go home. If somebody has a bad time, they only have themselves to blame (or maybe an offending coworkers).
  • by JaredOfEuropa ( 526365 ) on Friday July 13, 2007 @04:59AM (#19846789) Journal
    So aspriring project managers do not need books like Lister's, they can just read your post and know all there is to know? The point of books like these is to take a critical look at the set of common practices you call "basic project management", examine the good and bad parts, and suggest better alternatives.

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


    Lister talks about getting the right people for that project, and that means that you don't fully staff it before you know what you're going to need.

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


    There are still managers out there who think that the specs that were agreed up front are set in stone, and not to be changed. Even if you do change them, when do you adjust the specs and how do you go about it? As far as I can see from the short article, these are questions addressed by this book.

    There are enough managers who still royally screw up the "get people", "build the team" and "adjust specs" jobs, to warrant a book on the subject. There are a fair few out there already and I haven't read this one, but if Lister's previous work is anything to go by it might be a worthwhile read.

    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.


    I tend to agree with you there, but you can be a bit more creative than either doing nothing to socialise or saying "we *are* having drinks this Friday afternoon". A manager can certainly make a difference in how a team bonds, and for those managers I have three magic words: "during office hours". Take the team out for a nice 3 Martini lunch, or an afternoon of paintball. The cost of doing this during work hours looks daunting on the spreadsheets, but it will generally earn itself back a few times over.

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...