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."
He forgot one (Score:5, Funny)
And you forgot one. (Score:5, Funny)
Re: (Score:1, Funny)
Oh, looks who's talking...
No she didn't! (Score:2, Funny)
Re: (Score:3, Informative)
Re:He forgot one (Score:5, Funny)
Specializations of the WMP pattern invoke a whore_method() call, with returns along the lines of:
- Cheesy sex tape leak
- Customs bust while travelling
- Messy divorce, with optional taped calls to children
- Wardrobe malfunction
- Altercation with police, typically un-sober
- Provocative language directed at another media/political personality
- Endorsement of whacky fad (911-truther, Holocaust denier, global warming radicalism)
The whore_method() takes no arguments initially, but always throws a very public exception, littering the cable news stack with arguments.In the absence of actual news, natural disasters, or death-porn, these arguments can reverberate on the cable news stack for weeks, becoming tedious.
The quality of the product varies inversely to the tastelessness of the whore_method(): real artists just deliver the goods.
Yet another /vertisment.. (Score:4, Interesting)
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
Re: (Score:3)
That's not what a quicky article is for. And the book sounds interesting enough after reading the blog entry that I'd consider buying it. I recognize the brownian motion pattern (been there), the dead fish pattern (been there), and if I had the book, I'd probably recognize a few others.
The books' value is two-fold: an interesting read, and being able to put it under other people's noses and say "Hey - THIS is what we should be doing!" I'm a big fan of the "test before you test" pattern, the strawman - t
Most Programming is not an art (Score:2)
Re:Most Programming is not an art (Score:4, Insightful)
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.
Re: (Score:1)
Re: (Score:2)
Ummm ... No.
Re: (Score:2)
That's all well and good, but there's still a subset of us who are interested. I certainly don't go and bitch about Amiga articles because they're there.. but, that's the Internet. Someone's gotta complain, especially if it's free.
Re: (Score:2)
Isn't that basic Project Management? (Score:5, Insightful)
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: (Score:2)
Institutionalize It (Score:5, Funny)
Obviously, you hold their families hostage at an undisclosed location until the conclusion of the bonding is complete. [wikipedia.org]
Re: (Score:2, Interesting)
Well, yes (Score:2)
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 socializ
Re: (Score:3, Insightful)
It would also appear from the interview snippet that the authors plan to use a patt
Re: (Score:1)
As them for first-hand evidence that a waterfall project has ever met the needs of its users and ended on time and at budget.
You might not want to try this if you work for NASA. I hear they actually do have one example.
Re:Isn't that basic Project Management? (Score:4, Interesting)
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.
Re: (Score:2)
How timely.
Last month, our GM had scheduled for the whole office to go to an afternoon baseball game on a Thursday. Unfortunately it got re-scheduled due to the game being rained out. No biggie, it happens.
The re-scheduled event is today, we're going to a football game.
In the evening.
A friday evening.
Staff only.
I think less than half of the staff are going, as opposed to nea
Yes and no (Score:4, Insightful)
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: (Score:3, Insightful)
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 w
Re: (Score:2)
Re: (Score:3, Informative)
So you've missed the most basic thing of all.
Be careful in oversimplifying for no purpose other than to be dismissive of somebody else's opinion or even expertise. Being modded insightful by Slashdot on people issues isn't much of an endorsement.
Re: (Score:2)
As for not wanting to hang out with your co-workers...that is indicative of the quality of our coworkers (i.e., they probably suck). I would love to hang out with my coworkers. As soon as my company hires a few competent human beings, I'll be all over it!
Re: (Score:2)
Basic reading comprehension is another important skill. It's just a shame that you answered the article without bothering to either read or comprehend it first.
In what way is "setting up opportunities for people to get to know one another outside of work" equivelant to "[institutionalizing] getting together with your co-workers after work just so you can bond"?
If I wanted to pay someone money to fix my development process, I can be pretty sure that the only thing I'd pay you for is to obtain Lister's p
Dreamtime. (Score:1, Informative)
We need more project sluts (Score:5, Funny)
What do you mean not that type of slut?
Re: (Score:1)
Re: (Score:1)
I kid, I kid!
Re:We need more project sluts (Score:5, Funny)
You are posting on
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
"You are posting on
Not as hot?
I kid.
Re: (Score:2)
Re: (Score:1)
Re:We need more project sluts (Score:4, Funny)
Re: (Score:2)
Re:We need more project sluts (Score:5, Funny)
You do realize that if management hired her and she was up to the usual standards she'd be inept in the sack, be ugly and have about 3 good teeth...and if women were scarce it would be a fat alcoholic man in a dress. You'd then be told you had to make do, bring it across the line, take one for the team etc. etc.
Re: (Score:1, Flamebait)
I'm not sure what you're saying here. That any female with technical proficiency must be ugly as hell?
And then you guys wonder why you can't get dates.
Re: (Score:2)
It was a dig at management hiring practices not a dig at women (hiring someone incompetent and ill suited to do a job). You must have worked really hard to misread that into an attempt to belittle intelligent women. I would think if you were going to attack anything it would be the initial use of the word 'slut'. So take your femo-nazi bullshit elsewhere. Oh and by the way I'm not looking for a date thanks: I'm getting married
Re: (Score:1)
Re: (Score:2)
Close, the term you are looking for is conslutant.
(Best typo of consultant on
Re: (Score:2)
Re: (Score:1)
not quite as annoying as expected... (Score:4, Funny)
His Answer (Score:2)
Where we bang any project that has a spec?
It depends how long the spec is.
Re: (Score:1)
For project development, that is. My GF assures me elsewhere, size does matter...
Re:His Answer (Score:4, Funny)
No best practices... (Score:5, Funny)
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!!
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
While I agree with you that talking about positive things is more important, I have to say that as a person who currently working on a dead project, I found this article to be very helpful. At least as a reference: now I can tell my boss, why I think our project was born dead and refer him to this article.
From TFA (Score:2, Funny)
Well Adolf Hitler comes to mind, I know that name
Re: (Score:2, Funny)
Re: (Score:2)
Corollary to Godwin's law: As an online discussion grows longer, the probability of mentioning Mike Godwin approaches one.
Re: (Score:2, Informative)
Re: (Score:2)
Missed the Gang Bang pattern (Score:3, Insightful)
strawman (Score:4, Insightful)
Yes, it's an awesome idea until some PHB doesn't realize that software development is like and iceburg [joelonsoftware.com] and forces dev to use the prototype as the production version.
"But, it looks 90% done!"
Re:strawman (Score:5, Interesting)
Re:strawman (Score:5, Funny)
Re: (Score:1)
Re: (Score:2)
Re:strawman (Score:5, Insightful)
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.
Re: (Score:2)
And there is a difference between coding before the specs are set in stone, and building over a prototype. Its 2 totally different, 100% unrelated things.
Re: (Score:2, Interesting)
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 pr
Re: (Score:2)
"dead fish" reinvents Yourdon's "Death March" (Score:2, Insightful)
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 s
Re: (Score:2, Insightful)
Re: Bad News / Kicking the Can down the road (Score:1)
Re: (Score:2)
Application software vs system boundaries. (Score:2, Informative)
A pattern that is probably completely beyond their competence horizon is where the application developers do not know where the
Has the Sun set on the Pattern Competence Horizon? (Score:2, Funny)
Re:Has the Sun set on the Pattern Competence Horiz (Score:1)
I hereby summon Phil, The Prince Of Insufficient Light!
Not surprised by /. reaction thus far (Score:3, Insightful)
Re: (Score:2)
Defensive or just tired of seeing yet another medicine show promising to cure all ills with their wonder tonic?
Re:Not surprised by /. reaction thus far (Score:5, Insightful)
Re: (Score:2)
From QA to PM (Score:2)
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
Re: (Score:2)
I could see this point on smaller projects, but I was referring to very large projects. On the ones I am working on, we actually go through the phases of the waterfall methodology. So the requirements phase may start now, but the project wouldn't get to coding for another 5 m
Re: (Score:2)
The "management always knows best" screeds
Re: (Score:2)
The low man on the totum pole usually knows better (Score:2)
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.
Re:The low man on the totum pole usually knows bet (Score:2)
Good summary ... (Score:2)
Don't use words like that please (Score:1, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
I Knew! but had to read it anyway (Score:2)
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.
Browse at -1 you whiney bitch AC! (Score:2)
Re: (Score:2)
There, fixed that for you. ;)
Of course, that only applies to /. itself. Following unknown links in comments, especially from ACs, is probably unwise in a working environment. (Actually, nevemind "work safe", goatse isn't "mind safe")
Re: (Score:1)