| Date: | March 21, 2007 / year-entry #101 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070321-00/?p=27543 |
| Comments: | 45 |
| Summary: | Many years ago, I saw a Dilbert cartoon that went roughly like this. Frame 1: Supertitle - "Dogbert's guide to project management." Frame 2: Supertitle - "Not a project." Dilbert answers the phone. "Sure, we do that." Frame 3: Supertitle - "A project." Dilbert answers the phone. "No, we don't do that."† I've seen a... |
Many years ago, I saw a Dilbert cartoon that went roughly like this. Frame 1: Supertitle - "Dogbert's guide to project management." Frame 2: Supertitle - "Not a project." Dilbert answers the phone. "Sure, we do that." Frame 3: Supertitle - "A project." Dilbert answers the phone. "No, we don't do that."† I've seen a lot of software projects, and one thing I've learned is that you don't have a product until you start saying "No". In the early phases of product design, you're all giddy with excitement. This new product will be so awesome. It will slice bread. It will solve world hunger. It's designed for everybody, from the technology-averse grandmother who wants to see picture of her grandkids to the IT manager who is in charge of 10,000 computers. It'll run equally well on a handheld device as in a data center. When I see a product with an all-encompassing description like this, I say to myself, "They have no idea what their product is." You don't know what you do until you know what you don't do. And the sooner you figure out what you don't do the better, because a product that promises to do everything will never ship. As long as you wallow in the "Sure, we do that" stage, you're going to flail directionlessly, and the less likely the final product will actually solve the problem you set out to solve. Whenever I see a project description, I pay close attention to the section titled "What we don't do." That tells me how serious they are about shipping. And if there isn't a "What we don't do" section at all, I sigh quietly, since that tells me that they don't yet know what they do. †Commenter Thomas successfully tracked down the cartoon I was thinking of. |
Comments (45)
Comments are closed. |
What doesn’t Windows Vista do? :-)
"What doesn’t Windows Vista do? :-)"
Merrion: it doesn’t store everything in a database filesystem. That was one of the no answers that allowed it to ship.
—“What doesn’t Windows Vista do? :-)”—–
What you expect it to.
I’m not trying to nitpick here, but do you mean that last sentence literally? I agree with the basic sentiment, but I’d think that “what we don’t do” is going to be implicit in most cases (and arguably infinite). For instance, if I was writing a calculator program (like the one in XP PowerToys), I wouldn’t feel the need to say “This program doesn’t play mp3 files”. It might be useful to rule out the things that people would expect it to do, but then you’re into a grey area. (Would people expect to be able to do arithmetic in any arbitrary base, or just binary/hex/denary?) I’d be more in favour of just listing the things that the product will do, and then saying “If it’s not here, it won’t happen”.
drawing on the calculator example in a planning stage. Will it do function graphics? Will they be 2D or 3D?, can be customizable to do any Math function?, What about Trigonometry functions?. or Physics functions? or Astronomy functions?.
The answering of these questions whether yes or no is not just to say what features you don’t have, but more to make you focus and realize what you will actually provide and what not within the context of the product.
Hey, I thought everyone learnt the power of No back when they were three years old. Of course, I don’t say it often enough.
Surely it’s possible to have a clear idea of the product, and a concise description of what it does do without needing to spell out the explicit noes though? But I guess someone will always find an edge case you have to say no to.
I’m arguing with myself now, I shall stop.
Raymond: What do you think is the ideal stage of project development where to decide upon the "What we won’t do" clause? It would seem obvious to me that you know some "don’t do"s at the beginning already, but surely many will also follow during the project implementation.
And then there’s the consideration of the customer, it seems a bit abnormal you’re telling them what your project doesn’t do .. that doesn’t seem like good advertisement to me.
I also think it’s often practically impossible to list all the (important) things a project won’t do, an OS is of course one of the perfect examples for this, but as JohnCKirk said, even a calculator could cause a grey area .. since the target audience may not be well defined.
I’ll definitely keep your hints about this in mind though, I already have the "What I’ll do" clause for my graduation project, but didn’t really consider the other one yet .. even though with every assignment we get you can count on me mailing the instructor with questions like "Does it have to do X or not?"
I remember that one. It, or one very similar, is on page 101 of “Build a Better Life by Stealing Office Supplies”. That one starts with Dogbert saying “All companies need a strategy so the employees will know what they don’t do”. With no strategy, Dilbert is looking at a ringing phone and thinking “Uh-oh, what should I do”. With a strategy, he’s answerd the phone and is saying “We don’t do that”.
There’s a bit in the Dilbert Principle, where someone had emailed Scott Adams saying that their company recently distributed strategy business cards, with a note telling employees to challenge any requests that don’t appear to be part of the strategy (page 296).
PingBack from http://flyingupsidedown.wordpress.com/2007/03/21/you-dont-know-what-you-do-until-you-know-what-you-dont-do/
Messiant R:
"And then there’s the consideration of the customer, it seems a bit abnormal you’re telling them what your project doesn’t do .. that doesn’t seem like good advertisement to me."
Your marketing department doesn’t take the list of "stuff we don’t do" to base its advertising campaign around. Your developers, testers, and management take the list so they have a clear idea of what the goals are of the project and what’s going to constitute a finished project. Another form of a "we don’t do this" list is "we’ll do this in a future release".
"even a calculator could cause a grey area .. since the target audience may not be well defined."
Who are you planning on selling your product to if the target audience isn’t well defined? Anonymous already posted some examples of narrowing a calculator project’s scope. The calculator that ships with windows is a good example of a general-purpose calculator. One thing it doesn’t do is financial calculations, which the calculator that ships with Ubuntu does do. Both calculator products obviously have a very narrow scope compared to, say, a TI-93 or an HP-48g or whatever the latest thing is these days. Just based on the number of hardware calculators out there, it seems obvious to me that calculator projects need a "we don’t do this" list just as much as everything else.
"I’ll definitely keep your hints about this in mind though, I already have the "What I’ll do" clause for my graduation project, but didn’t really consider the other one yet .."
Don’t bother. School projects are stupidly simple compared to a real-world project, and it’s really not necessary.
My feeling has always been, if the project/product specification doesn’t say that it WILL do it, then it WON’T do it.
Unfortunately, the people that should be looking at the specification the closest (ie. marketing) usually don’t read it anyway.
Sometimes I think its intentional. That way they can squeeze in more features by claiming ignorance.
There is also an evil variant of "we don’t do that": the managers which get by with this a few times and then start to answer to any request from the others (users, upper management) with "we don’t do that".
Remember all that companies that once mattered something and don’t exist anymore. Somebody there gladly proclaimed "We don’t do that" when he shouldn’t. PC’s? "We don’t do that." Windows application? "We don’t do that." Internet? "We don’t do that".
Especially nasty is when apparent technology limitation is used for excuse, like: "We don’t do that because our
design is object-oriented |
code uses the latest C++ standard |
code uses dot net 2 |
code uses STL |
code uses Boost |
code uses UML |
(etc)
"
If the management doesn’t understand what’s going on, the company is in a big problem.
Unless the company can’t destroy its monopoly with such decisions. Then, the result is typically "only" tortured users.
Some people seem to be struggling here. The idea is not to establish a complete list of “No” items for your project, but just that a project scope which doesn’t have any “No” or “We don’t do that” items at all is probably incomplete.
It’s conceivable that your project is so narrowly focused that this isn’t a problem, but it’s unlikely.
One day in primary school my teacher asked me after class to clear the acetate on the overhead projector. The roll was nearly exhausted and she just needed enough space to put some simple instructions up after lunch. But I didn’t know that, I’d never seen a teacher fetch a blank roll from stores so I figured it was part of the machine, and cleaning it was just one of those tedious things grown-ups did all the time. So I set to work.
My teacher hadn’t limited the scope of the project. To her it was /obvious/ that I only needed to spend a minute or so rubbing out the current page with a cloth, and then I’d go for lunch. So you can imagine that she was surprised when she got back to find me still there, hands covered in ink and having erased a substantial portion of the term’s class notes.
“We don’t do that” also prevents people from mistakenly assuming that you’re going to do something which actually you can’t or won’t do. Since happiness is the correct setting of expectations you can make people happier just by telling them “We don’t do that” rather than wasting their time by saying “Yes” and then not delivering or by leaving the question unanswered.
[ … using it as an opportunity to hurl insults]
It’s important to operate with the assumption of good faith. For example when I’m misquoted in The Old New Thing it’s much more likely to be a clumsy attempt to paraphrase than a deliberate effort to discredit my opinion. Similarly when a comment seems critical of Microsoft, or unfair in some way, you should take it in good humour, as you hopefully would if it came from a colleague.
This has to be one of the best posts of all time for shear quote-ability. I am so forwarding this to the PM on the current project I am working on. He has already got us in hot water twice telling clients "sure we’ll do that" after I have told him in no uncertain terms "no we will not do that with this software". Then we have to eat dirt for a bit with the client because he has to go back and explain to them that he was wrong and we don’t do those things but if they want them they can contract us to write a different piece of software that will.
Communication is a funny thing. Words are really just little symbols for concepts in our heads. Sometimes, the concept in my head is different than the concept in your head. So even a reasonably detailed functional specification will leave people with differing expectations. Elaborating the tasks that you will NOT do helps to get the same picture into everyone’s head.
This reminds me of something I once saw a Product Manager/Dev Lead at Apple write once – paraphrasing from memory:
"I was lead for about 7 years, and the job mostly consisted of saying ‘No.’ When that didn’t work, ‘Hell, no!’"
Reminds me of a marketing lad I was talking to once. Someone asked him "Will it do such-and-such". And the answer was "Sure it will do such-and-such. What exactly is such-and-such?"
I wholeheartedly agree with this, Raymond. I managed a project that failed because we refused to deny any features. I guess you could say it got too top heavy and collapsed.
I learned two things from this – pick one direction to go in (at least at first), and to design bottom up rather than top down (although this may not apply for everyone).
It’s not just about saying "no" to things that your product should never do, or that it will obviously not do.
It’s about saying "no" to some possibly very desirable features to reign in the product and get serious about shipping.
I believe this truism is indeed very true: You can tell when a product has turned the corner and is converging on shipping when you start seeing "no" decisions stick, even when you’re saying "no" to things that some people feel passionately are "yes".
Ahh, the hallowed halls of Chenland. It’s good to be back. :)
On the subject of project management, I would recommend reading "Dreaming in Code" by Scott Rosenburg. You can find some information about it at http://www.dreamingincode.com/ . It’s about Mitch Kapor (the guy who wrote Lotus 1-2-3) and his project to write the be-all-end-all Personal Information Manager (PIM), code-named "Chandler". As a software developer it’s hard to read lay-books about software development, but this one was good if only because it brings to the fore: 1) how necessary good management is, 2) the need to say "No", and 3) the need to commit to making a decision. Chandler was designed by committee, and every time they’d bring on a new person with fresh ideas it was back to square one in the design process. After three years and more than a million dollars they never produced anything useful.
To me, "Dreaming in Code" pretty much makes Raymond’s case.
Oh. I forgot to mention that I am not affiliated with the author or publisher of "Dreaming in Code". I just thought it was a good book.
The software company I worked at always had extremely narrowly focused projects, we never had a no list and it never stopped us from shipping anything. It never delayed anything either.
I can see how a no list would help on more generic projects, though.
Actually, there was another company I worked for that built custom software for customers, they didn’t have a no list either but had a clause in the contract that any feature not explicitly defined, no matter how obvious its inclusion should be, will not be included in the project and should its inclusion be required, the customer will have to wait longer and pay more for their software. This did lead to some disgruntled customers occasionally, but again allowed us to get stuff out on time. A no list would have probably helped a lot because it would have eliminated confusion about what was going to be in the project.
I assume you’re talking about the company that HAL 9000 in 2001: A Space Odyssey is supposedly named after. Calling their email client "torture" is an understatement.
I deliberately avoid "don’t do". Instead, I add *every* suggestion to the to-do list.
But, I categorise suggestions. Some are split by which planned release they should be included in. After that is "do someday", for items which are necessary, but not yet scheduled for inclusion. Finally, "wishlist" is for currently-impractical concepts.
There’s no "don’t do" in there, because that’s too restrictive. There’s a definite focus on what we *should* do, in what order, and a recognition of what we shouldn’t be wasting our time on right now, at least according to our current information.
A board game (thud) is an example: 3d graphics used to be "wishlist", now it’s "future release". Skinning used to be "do someday", now it’s "current, RC1". Meanwhile, "java 1.1 rich text" has moved all the way from "next release" to "wishlist" (reluctantly replaced by Swing, and a huge respect for MS’s rich text handling).
A categorical "don’t do" list is a very good idea for a large company, with enough resources that it *could* do anything if it didn’t watch out what it was wasting time on. But for an Indie developer, flexibility is king, and the ability to change focus with market interests is far too critical an advantage to give up.
@Dewi Morgan
There is an implicit list of "we don’t do" and you are heavily using it anyway.
The first line of code you write already sets the donts.
Even "winmain". You’ve already decided on a GUI app and not a service which can be used remotely through a browser or a console app via telnet.
On the calculator example, the format and way you store numbers will decide your precision in divisions, your calculation speed, etc.
The advantage if you set your "don’t" list in advantage (and get it approved by management with blood) is that you can use it (or at least some points of it) as constraints for your development.
For example if you can restrict yourself to IEEE-754 64bit precision, the calculator is a much easier project than if you require complex numbers in base 200560490130*, infinite number of digits before dot, up to 1024 digits after dot, 1024 digits of exponent, 1bit of sign.
(*) = it’s the product of all prime numbers from 2 to 31. This mean that numbers under this "convention" can be divided with a finite number of digits when the divisor has only prime factors between 2 to 31.
—-“[Sometimes I wonder why I enable comments. I was apparently misguidedly optimistic that people would discuss project planning instead of using it as an opportunity to hurl insults. -Raymond]”—–
[off-topic comments deleted]
And it’s your fault for not limiting the scope. You should have put a clear note stating “pithy repartee not allowed”, or, considering the tone of your comment: “we don’t do humor”.
And “The lunatics are running the asylum” should be an obligatory reference before starting any discussion on project scope.
Touchy today Raymond! The truth is that rare is the piece of software that does what it is expected to do consistently over a long period of time. Unless producing unpleasant surprises is part of the spec.
We could probably institute the HAL awards for apps that do what they want to do and not what the user might reasonably expect, but if time wasted is anything to go by I suspect that MS Word, like the Nile Perch, will gobble up all the opposition.
[off-topic comments deleted]
Not cheap shots, just legitimate objections. There’s a reason why I still use win2k or corporate versions of XP.
Raymond appears to be suffering under the illusion that I’m making ‘cheap shots’ against MS; I’m not. I’m attacking software developers in general.
[long off-topic rant about some buggy product deleted]
[discussion of that buggy product deleted]
Funny … working in a large corporation my interpretation is that "what we can’t do" is what we say all the time … never what we can. Such a different thing than software development.
Following up on Dewi Morgan’s comment about categorising requests, my MSc project supervisor gave me some similar advice about a "Moscow" analysis. (I realise that this does slightly contradict my previous comment.) The Moscow approach is sort of an acronym: MoSCoW. The idea is to divide potential features into four categories:
M – Must do them, absolutely critical.
S – Should do them, if at all possible.
C – Could do them, if I have time to fit them in.
W – Won’t do them at all.
Mind you, this applied to a project of limited scope; although I’ve continued to tweak it on my own after finishing the MSc, it was never intended to go through several releases, so it wasn’t a case of "leave that until version 2".
I think it’s useful to fine-tune your requirements based on questions. Coming back to my calculator example, I could see the process going like this:
a) "This calculator will allow you to do arithmetic in different bases."
How about base 47?
b) "This calculator will allow you to do arithmetic in all bases between 2 and 12".
How about base e?
c) "This calculator will allow you to do arithmetic in all integral bases between 2 and 12".
And so on. The idea would be that if someone files a bug report because they want to do arithmetic in base -2.7 then you can point at the specification and say "not by design". If you get particular questions a lot, it may be sensible to put them into a FAQ just to reduce the amount of time you spend answering them, but I’d count that as a support team issue rather than a sign that the project managers don’t know what the product is supposed to do.
Final disclaimer: although I’ve been programming for years, I’m still fairly new at the project management side of things, so my ideas could well be misguided.
[further off-topic discussion of that buggy program deleted]
… of course, I’ve never had $10 billion to play with.
>>It’s designed for everybody, from the technology-averse grandmother who wants to see picture of her grandkids to the IT manager who is in charge of 10,000 computers. It’ll run equally well on a handheld device as in a data center.
When I see a product with an all-encompassing description like this, I say to myself, “They have no idea what their product is.”<<
Err… treading lightly here… but isn’t that how Windows is described?
PingBack from http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a76eab63-70f0-48b4-8b75-66c366a651cd
I’m even more radical: I believe a project should do exactly *one* thing, and not do everything else. If you want to do two things, set up two projects.
[I suspect eBay doesn’t run Windows CE]
I always thought it was a pair of Timex Sinclairs strapped back-to-back.
PingBack from http://www.rp0229.com/blog/2007/03/24/great-post-on-deciding-what-not-to-do-via-raymond-chen/
PingBack from http://wanderr.com/grooveshark/you-dont-know-what-you-do-until-you-know-what-you-dont-do/2008/01/31/
PingBack from http://www.25hoursaday.com/weblog/2008/08/04/AvoidingTheSecondSystemEffectInSoftwareDevelopment.aspx
From elsewhere in the collective.
PingBack from http://vamshidhar.wordpress.com/2007/03/26/scoping-software-to-make-sure-it-ships/