Slashdot Mirror
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.
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
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.
Another good book to read is: Dreaming in code by Scott Rosenberg.
I was looking forward to an update on project "Sluts and Strawmen".
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?
Interactive Visual Medical Dictionary
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.
/. has never been safe for work. Unless you work someplace cool.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
"My dad once said, "it's hard to hate someone when you know their name."
...
Well Adolf Hitler comes to mind, I know that name
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.
Sir... are you trying to make us into "project sluts"?
Where we bang any project that has a spec?
It depends how long the spec is.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
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).
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!"
Rackspace??? Maybe it isn't just for hosting.
... but in the more traditional sense.
It was actually a typical example of the Anonymous Coward pattern
[["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."
What I find laughable about this post and the Atlantic Systems Guild in general is that they seem to think that a system is only about software. A system is about far more than just application software, especially in a enterprise production environment where things like security, system monitoring, back-up/restore, operations etc are just as important as any end user experience.
A pattern that is probably completely beyond their competence horizon is where the application developers do not know where the boundaries of the system are.
I'd call this waltzing in the dark.
I don't understand why are these supposed to be relevant to software engineering ( not comp science). This is true for any engineering activiy. I simply don't agree that software engineering is much more complex than Designing a product or civil engg. I think they are even more complex as the constraints can be more physical in nature with a much larger number of people involved.
The Google query (( "KICKING THE CAN DOWN THE ROAD" debt social )) verifies this latest catchphrase for what is indeed such a fundamental issue. (( "Tragedy of the Commons" HARDIN )) fetches Garrett Hardin's Ur-Rant on this. Another favorite game-theory-phrase is "Individually Rational". I have read a couple of Hardin's books, what I like best is his recognition of "Adverse Selection" - yes you can call for sacrifice, and some people will, and then those folks are Gone... War isn't about who's right, it's about who's left.
Are the abstraction heuristics beyond further synergy? Can Idiomatic Representations still be Frameworked into Generic Self-Similarities? Is the bullshit stinking so bad that even the middle management is shying away from the cows?
There's a free eBook of 'Eric Sink on the Business of Software' available on the site too. Great book - full of insights.
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.
Sounds like PHB lingo to me.
I hereby summon Phil, The Prince Of Insufficient Light!
Knowing Google's lust for data collection, the Soviet Union is still alive and well inside the psyche of Sergey Brin....
I'll take the threesome. Thanks.
Put identity in the browser.
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
A polar bear is a cartesian bear after a coordinate transform.
America, Home of the Brave.
I'm posting this from a different machine to my normal office workstation because my corporate firewall blocks the slashdot front page due to that sl*t word.
AC, you ignorant slut.
I work for a very large bank (actually, now the largest in the country) and am a software testing project manager. I did QA and testing for about 13 years before this, and never had much respect for PMs becuase I never really saw what they did as work. Now that I am doing it, I still don't quite feel that it is hard work, but it sure takes up a hell of a lot of my time. In my experience, although there are many problems with software development, one of the *worst* is "best case syndrome". This affects everyone, from business analysts to architects to developers to testers to implementation. Here is the gist of it: you ask someone for an estimate on how long something will take, and they give you a best case scenario. You compile a whole project of best case scenarios, and you are doomed to fail. It amazes me that this happens over and over and over.
"Well, if everything goes ok, we should be able to be done by...."
STOP! I have never seen anything work out to best case. Never. Sure, maybe a task or two get done early, but overall if all I get are best case estimates, we are in deep doo-doo. Because schedules will be made around those, and other things that hinge on upstream tasks will get pushed out. You know who gets screwed in the end? Testers. Because if requirements deadlines aren't met, or coding deadlines aren't met, people think it can just be absorbed somewhere. Then your testers end up working weekends and OT to try and make up the difference. And if *they* gave you best case estimates, you are dead. You'll never make up the time and have to scramble to figure out what is going to happen. THEN if your project gets put on hold until a later date, everyone gets the feeling that they just wasted all that time and effort. OR, the project gets implemented anyway, and you spend all your time trying to fix crap in production, and explaining to management what went wrong.
In the end, software development is still pretty much a crap shoot.
My beliefs do not require that you agree with them.
I knew damn well 'Project Sluts' wouldn't be what I hoped, and went and read the article anyway. Damn tease sucked me in without any follow through...
I was kinda hoping for something like the cute dev who gave many of us lap dances at an office party before the bubble burst in 2000.
I love the word slut. I picture beautiful women willing to give it up. To see the hottest women I found on myspace today, check out my web collection http://myspacecollector.com/
People that actually do real work know more about the project then the PHB. Why is that hard to understand?
Granted in the case of the .001% of managers that could find their ass in broad daylight with a map you might have a point. You don't sound like one of them so I'd say the discussion is moot.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Well, yes, if it's well organized and everything, it can work and I've seen it work even without any freebies (though they help.) No arguments there.
What makes people shudder at the thought of institutionalizing it, though, are experiences of places where it was institutionalized in all the wrong ways. E.g., they were mandatory (complete with roll call or signing your name on a list, and emails reminding everyone that they damn better have a great excuse if they dare not show up), _and_ instead of socializing it was having to listen to the boss do an ego-masturbation speech for 2 hours (for bonus points: with powerpoint charts), _and_ they happened entirely too often for something that bad an idea (e.g., weekly), _and_ just to rub everyone's nose in, complete with reminders that you're forbidden to put it on your timesheet.
At that point it's even irrelevant if they gave the people free beer and pizza, or (as was often the case), nothing whatsoever.
I mean, seriously, if someone's (A) required to be there, and (B) can't even just relax and socialize, but are required to sit through someone's presentation, then it's work. It's not a social occasion, it's just a meeting at work. Requiring it to happen on someone's free time, isn't going to make them happy. Giving them a free pizza and a beer for it, if anything, was insulting in its own right: noone was _that_ poor as to, basically, work two hours for food. At, say, $10 worth of pizza and a beer, that's 5$/hour for the boss's speech alone, which, frankly, was way below the hourly fee of anyone present in the room.
It doesn't even help with team building, since (A) if everyone is required to sit and listen to the boss's presentation, there's almost no time to actually socialize with other employees, (B) half the people are in a cranky mood just because they were required to be there again, which doesn't help make friends, and (C) everyone ends up _hating_ the mandatory idiots who ask some redundant question just to show participation.
Again, I'm not claiming that all such events _must_ be organized like that. Of course, there are people who do it right. On the other hand, it's entirely too easy to do it wrong, and God knows there's no shortage of PHBs with a natural knack to do things the wrong way. (Usual disclaimer: by PHB I really only mean the clueless gang, not every manager.)
And institutionalizing it as some corporate rule just begs such mis-haps to happen. People who have no skill in doing it right, or are the first to hate having to do it, end up organizing such events the wrong way just because the rules require them to.
In a way, the GP is right: do it when you feel it's the "right" time and when you think most people would find it fun. You can even make it some kind of pseudo-reward, like, "woohoo, we had a successful release, let's have an unofficial party at the pub." It's not just a good excuse, it shows people they're appreciated. _Don't_ do it just because the rules/nice-book/whatever say you have to do it and the time is up for the next one.
A polar bear is a cartesian bear after a coordinate transform.
But a project manager (in smaller organizations) is right in there with the sleeves rolled up. Higher management are the clueless jerks, and I think the author pointed that out pretty well in just the short interview.