programming and human factors
by Jeff Atwood
Although I love reading programming books, I find software project management books to be some of the most mind-numbingly boring reading I've ever attempted. I suppose this means I probably shouldn't be a project manager. The bad news for the Stack Overflow team is that I effectively am one.
That's not to say that all software project management books are crap. Just most of them. One of the few that I've found compelling enough to finish is Johanna Rothman's Behind Closed Doors: Secrets of Great Management. She co-wrote it with Esther Derby.
After reading it, you'll realize this is the book they should be handing out to every newly minted software project manager. And you'll be deeply depressed because you don't work with any software project managers who apparently have read it.
I originally discovered Johanna when one of her pieces was cited in the original Spolsky Best Software Writing book. Her article on team compensation (pdf) basically blew my mind; it forced me to rethink my entire perspective on being paid to work at a job. You should read it. If you have a manager, you should get him or her to read it, too. (Update: this essay is actually by Mary Poppendieck, who is also great. I'm leaving it in the post because it's fantastic reading, even if it's a little off topic.)
Since then, I've touched on her work briefly in Schedule Games and You Are Not Your Job. But I'd like to focus on a specific aspect of project management that I'm apparently not very good at. A caller in Podcast #16 took me to task for my original Stack Overflow schedule claims way back in late April. What was supposed to be "6 to 8 weeks" became.. well, something more like three months.
My problem is that I'm almost pathologically bad about writing things down. Unless I'm writing a blog entry, I suppose. I prefer to keep track of what I'm doing in my head, only anticipating as far ahead as the next item I plan to work on, while proceeding forward as quickly as I can. I think I fell prey, at least a little bit, to this scenario:
"Look, Mike," Tomas said. "I can hand off my code today and call it 'feature complete', but I've probably got three weeks of cleanup work to do once I hand it off." Mike asked what Tomas meant by "cleanup." "I haven't gotten the company logo to show up on every page, and I haven't gotten the agent's name and phone number to print on the bottom of every page. It's little stuff like that. All of the important stuff works fine. I'm 99-percent done."
Do you see the problem here? I know, there are so many it's difficult to know where to begin listing them all, but what's the deepest, most fundamental problem at work here?
This software developer does not have a detailed list of all the things he needs to do. Which means, despite adamantly claiming that he is 99 percent done -- he has no idea how long development will take! There's simply no factual basis for any of his schedule claims.
It is the job of a good software project manager to recognize the tell-tale symptoms of this classic mistake and address them head on before they derail the project. How? By forcingencouraging developers to create a detailed list of everything they need to do. And then breaking that list down into subitems. And then adding all the subitems they inevitably forgot because they didn't think that far ahead. Once you have all those items on a list, then -- and only then -- you can begin to estimate how long the work will take.
Until you've got at least the beginnings of a task list, any concept of scheduling is utter fantasy. A very pleasant fantasy, to be sure, but the real world can be extremely unforgiving to such dreams.
Johanna Rothman makes the same point in a recent email newsletter, and offers specific actions you can take to avoid being stuck 90% done:
- List everything you need to do to finish the big chunk of work. I include any infrastructure work such as setting up branches in the source control system.
- Estimate each item on that list. This initial estimate will help you see how long it might take to complete the entire task.
- Now, look to see how long each item on that list will take to finish. If you have a task longer than one day, break that task into smaller pieces. Breaking larger tasks into these inch-pebbles is critical for escaping the 90% Done syndrome.
- Determine a way to show visible status to anyone who's interested. If you're the person doing the work, what would you have to do to show your status to your manager? If you're the manager, what do you need to see? You might need to see lists of test cases or a demo or something else that shows you visible progress.
- Since you've got one-day or smaller tasks, you can track your progress daily. I like to keep a chart or list of the tasks, my initial estimated end time and the actual end time for each task. This is especially important for you managers, so you can see if the person is being interrupted and therefore is multitasking. (See the article about the Split Focus schedule game.)
I'm not big on scheduling -- or lists -- but without the latter, I cannot have the former. It's like trying to defy the law of gravity. Thus, on our project, we're always 90% done. If you'd like escape the 90% done ghetto on your software project, don't learn this the hard way, like I did. Every time someone asks you what your schedule is, you should be able to point to a list of everything you need to do. And if you can't -- the first item on your task list should be to create that list.
Horay! Jeff has discovered Agile!
Just few more years and object-oriented programming might follow...
As a project manager, I found this highly entertaining. If you're going to have to effectively do project management, you may have to learn some principles of project management, even if you are normally a programmer. In my organization we are lucky enough to have people like myself who can spend their time breaking tasks into WBSs and such, which give you much better estimates for completion. Once you have these tools, when you are monitoring a project you can ask better questions than What % done are you?, instead you ask questions like Which of these tasks are complete?, then you can go back and really figure out how much more time to complete the project.
Personally I've found percent complete is misleading, I'd rather know how much I've spent, how much I've earned, and what its going to cost to complete.
Scott on August 12, 2008 10:53 AMForcing works better than encouraging.
Now, that is just a stupid statement altogether.
Dave Schinkel on August 13, 2008 7:29 AMI couldn't disagree with this article more! I have responded to this post on my blog:
http://blog.robbowley.net/2008/8/11/lists
We are already living in the matrix, so there's no telling what is real even as you walk down the street :)
Craig Lebowitz on August 22, 2008 2:57 AMSome painters spend years perfecting their technique.
On the other hand, one particular painter I saw on TV just picks up a bucket of paint and throws it into the airflow of a Jet engine and the paint gets randomly splashed on to the canvas.
How long did it take to paint the Cisteine Chapel? And how long does it take to throw a bucket of paint in the air?
Michael Angelo's masterpiece took over 4 years to complete - Can you imagine ANY manager being happy with that?
The American painter who throws his bucket of paint in the air spent just under 30 seconds on his master piece and it sold for over $1M. Is this man over 4,204,800 times better at painting than Michael Angelo?
Which one is more famous?
There are no short cuts to quality.
If you want perfection it takes more than 5 minutes. If you want shit, don't ask a creative genius to sacrifice himself on the altar of your greed.
You only get out what you put in. The Universe works this way - No amount of management and pissing about will make the process any faster, only smoother, by making sure the 'creatives' have all the tools they need.
The only question a manager/producer/director knows or cares about is HOW MUCH MONEY CAN I MAKE AND HOW QUICKLY CAN I MAKE IT?
As soon as you all admit that, then management and creative people will have a better understanding.
How long will it take? TWO WEEKS - lol
In response to: Until you've got at least the beginnings of a task list, any concept of scheduling is utter fantasy. A very pleasant fantasy, to be sure, but the real world can be extremely unforgiving to such dreams.
Your statement is misleading. It implies there is a state where schedules are in fact not utter fantasy.
I do agree it is critical to write all these little things down. But they are not required to make a schedule. Schedules have varying degrees of precision, this technique can improve the precision of your schedule. (make it less utterous)
There is a folly though to think you should do this breakdown for every task on the schedule, up until the end date. You're understanding of what you need to do 3 weeks from now is vastly less than your understanding of what you need to do today. Creating a very granular breakdown of something you're doing in 3 months is potentially a useful exercise but it will not increase the accuracy of your schedule.
fschwiet on December 30, 2008 5:58 AMAnother practical project management book is Simply Brilliant by Fergus O'Connell. Well worth the read - and it's an easy read too.
Neil Watson on February 6, 2010 10:37 PMThe Poppendiecks should be more widely read.
This post resonates with me. I keep trying to use paper more to both block diagram and make lists before I fire up VS. I also try to write tests before the real code, but that doesn't always work.
I usually think about a solution before I implement it, but once I've split it up a little I think it's easy enough to just jump into the code. Then I wonder why it takes longer than I thought.
John Ferguson on February 6, 2010 10:37 PMSorry for implying the Poppendiecks should read more. I meant their work should be read by more people.
John Ferguson on February 6, 2010 10:37 PM[Poppendieck's] article on team compensation (pdf) basically blew my mind; it forced me to rethink my entire perspective on being paid to work at a job.
The article was indeed an interesting read; thanks for the link. It does a good job of illustrating how a performance review system that forces managers to rank their team members, when the team members' performance was uniformly high, can cause problems.
However, the article seems to take that one case, and propose a set of performance review guidelines based on lessons learned from that single case.
What about, say, the case of a team that really does have one or two superior performers relative to the rest of the team; or the case of a team whose performance was mediocre across the board? Do the article's recommended guidelines apply equally well for managers of teams in those situations?
I would have liked to see the first portion of the article (which focused only on the high-performing team) also discuss the other possible cases.
Jon Schneider on February 6, 2010 10:37 PMIt's really a simple concept: if it's even possible for a task to be 90% done, then you haven't broken it down enough. Every task should either be done or not done.
You can track elapsed time against estimated time, but that doesn't tell you how close you are to being done, only how close you are to a schedule slip.
Sadly, you're not the only one with this problem. Trying to get a work estimate out of some people is like pulling teeth.
Aaron G on February 6, 2010 10:37 PMI have had the pleasure of working with truly rubbish managers and directors. Men who have no idea about the development of software.
E.G.
Them - 'How long will it take to write this?'
Me - 'A year'
Them - 'Well I need it in 7 months'
What software producers don't realise is that it's a YEAR's worth of work - NOT 7 months. To deliver the product in the time they say do they pay for another programmer to assist in order to get the game finished on time?
No.
They expect you to suddenly double the number of working hours. Weekends gone, holidays - what holdays?
Sleeping on the office floor, being worked like a slave in a third world country and being driven to the point of absolute exaustion.
Development equipment that doesn't arrive until the project has started for two months...
I see way too much of this.
The life blood and creativity has been sucked out of the industry, programmers are no longer household names, just a number sleeping under a desk.
Does the book explain people skills, does it cover the fact that every day the programmer can't work because of lace of development kit the project should be extended by a day?
I could go on for a thousand pages detailing a litany of ignorance and bad management.
How long will it take you to complete the Times crossword today?
What do you mean you don't know... I need an estimate... NOW!
Ok, so you're saying you want to look at the crossword first.. er ok.
Right now you've had a look at the questions, how long will it take you to answer the questions you don't know the answer to?
I need an estimate... NOW!! Its ok, I'll hold you to your guess later so if you're late, I'll blame you. I'll look good and organised and you can look crap at your job.
Good programmers are like the hacker guys you see on TV.
Second 1: I've just broken through the pentagon firewall...
Second 3: (More keyboard rattling) ...now I'm linking from the pantagon through a NASA main server with 100 billion bit encryption... humm this is tough...
Second 4: Right I've just cracked the encryption and am bouncing the signal off a satellite now...
I honestly think directors/managers/producers are a thick as two short planks if they think this is how it works.
They can't program themselves because the're too stupid and they don't want to hear the truth about how long a program will take to write because they don't want to listen; anyway they always want it in half the time.
Business opportunity:
I want to invest some money in software development. I've heard that huge amounts of money can be made if you get it right.
Here's 100,000. Now I expect to make a 50,000,000 in almost no time at all because I'm a greedy, short sighted, ignorant, git and the only thing I truly understand is how to screw people out of money - which is why I have so much.
To make sure the programmer I employ hit's my own arbitary deadline, I'll employ one programmer and five managers to flap around and piss about making notes.
Then I can take the programmer off working on the project and get him to write the schedules, work break downs, bar charts, pie charts and graphs that the managers should be doing.
THEN the five managers need to look like they have work to do so the only way they can do that is to constantly badger the programmer.
Does the book solve problems like this?
Simon Nicol on February 6, 2010 10:37 PMI came up with a game design that was stolen by a BIG games company, the company I was working for at the time didn't see the potential of my design and so playing it safe they went for 'Die Hard 57 - OAP's revenge' (not the real name).
Am I arrogant in thinking my idea was much better than their 'safe' bet?
No.
Why? Because the game I designed went on (even though the idea was stolen) to become the world's biggest seller and the 'safe' game design though based on a very well known 'film' cost over 1,000,000 to develop and was a total flop.
The moral of the story: Let the designers and programmers design and program and the managers do what they're good at - Sweet FA.
Does the book have any suggestions on how to handle creative, intelligent people?
Quite often the situation I find is we cannot list down the things that need to be done at the minute level. If that happens, that means we have the design completely laid out in the clear, without having to *think* a single bit during the construction phase.
Have you ever found yourself in such a state? Knowing exactly when you will be done with a task/feature, by the hour? I have never.
I try to accomplish a task according to a rough plan, because I have _never_ done it before, so I can only follow a broad educated-guess approach. And then an error occurs, or unexpected behaviour or results are returned; dig around, step and debug, search the Internet or newsgroups for discussions or articles on said topic, post a question, wait for answer. Works on this machine, not the other. Make configuration inspections and tweaks. Guess what? two or four days have past.
Was that factored in? nope. Most of the time, the buffer schedule is never enough to cover for these hundreds, if not thousands, of small little and big issues popping up here and there and stalling developers.
Aaron Seet on February 6, 2010 10:37 PMTo any one who doubts whether this from the Poppendeick article is real, it absolutely is:
The Aftershocks - Two days later, Sue got a call from Janice in human resources. “Sue,” she said, “great job your team did! And thanks for filling out those appraisal input forms. But really, you can’t give everyone a top rating. Your average rating should be ‘meets expectations.’ You can only have one or two people who ‘far exceeded expectations.’ Oh, and by the way, since you didn’t rank the team members, would you please plan on coming to our ranking meeting next week? We are going to need your input on that. After all, at this company we pay for performance, and we need to evaluate everyone carefully so that our fairness cannot be questioned.”
That's exactly the way it was done at the last company I worked for, except as a team leader you probably weren't going to be fortunate (or unfortunate) enough to be invited to the meeting where they change all your scores for you. They called this the normalizing process; a nice bell shaped curve keeps the bonus amounts down. Of course, no one was told they'd be screwed like this when the company dangled the bonus out there in order to get people to accept lower starting compensation.
*Never* put any stock in the promise of bonuses; *always* assume that the salary you are offered is the only monetary compensation you'll ever see. In 15 years of doing this, I've yet to see a decent bonus. There's *always* been a reason not to pay them out in any meaningful amounts (slow economy, projects went under budget, we grew so much the profits were too low, etc.).
anon on February 6, 2010 10:37 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |