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."
Looks like yet another slashvertisment for an upcoming book/conference.
/real/ in-depth software engineering articles for once in a while?
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
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...
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!
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
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).
Liberte, Egalite, Fraternite (TM)
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.
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.
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.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...