Raymond Chen has a blog post entitled You don't know what you do until you know what you don't do where he writes

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.

In my five years at Microsoft, I've seen a bunch of projects fail. Some were public flame outs that are still embarrassing to mention today while others are private mistakes that you'll never hear anyone outside the b0rg cube mention. A few months ago I wrote a blog post entitled Top 5 Signs Your Project is Doomed and since then I've considered a few more entries that should be on the list bringing the total to 10. The list below are common signs that a  software project is doomed. Meeting one or two of these criteria isn't necessarily the kiss of death but three or more and you might as well start circulating your resume. 

  1. Trying to do too much in the first version. See Raymond's point above.

  2. Taking a major dependency on unproven technology.

  3. Competing with an existing internal project that was either a cash cow or had backers that are highly placed in the corporate hierarchy.

  4. The team is understaffed. If you have less people than can handle the amount of work you have to do then the right thing to do is to scale back the project. Practically every other choice leads to failure.

  5. Complexity is one of the goals of the project because "complex problems require complex solutions".
  6. Schedule Chicken

  7. Scope Creep

  8. Second System Syndrome

  9. No Entrance Strategy. When a project can't articulate how it goes from a demo or prototype to being in the hands of end users, there's a problem. This is particularly relevant in the "Web 2,0" world where many startups only strategy for success is getting a mention on TechCrunch and the fact that their service has "viral" features.

  10. Tackling a problem you don't know how to solve. It's pretty amazing how often I've seen this occur.


Categories: Programming
Tracked by:
http://21cdb.wordpress.com/2007/03/23/underpromise-overdeliver/ [Pingback]
http://wagnerblog.com/?p=794 [Pingback]
http://www.it-news.ro/2007/03/26/programming-top-10-list/ [Pingback]
http://www.u-g-h.com/index.php/2007/03/26/top-10-reasons-your-software-project-i... [Pingback]
http://www.benoitlavigne.com/blog/2007/03/26/around-the-net-11/ [Pingback]
http://intrablog.coloradotc.com/blogs/cbrown/archive/2007/03/26/top-6-list-of-pr... [Pingback]
http://drowningintechnicaldebt.com/blogs/royashbrook/archive/2007/03/27/select-t... [Pingback]
http://ranahammad.wordpress.com/2007/03/30/top-6-list-of-programming-top-10-list... [Pingback]
http://d3mon.wordpress.com/2007/04/20/top-6-list-of-programming-top-10-lists/ [Pingback]
http://host230.hostmonster.com/~betavisa/sitemap2.html [Pingback]
http://yftbsy1.net/lottery/sitemap1.html [Pingback]
http://otjjblj.net/03/index.html [Pingback]
http://restablog.dreamhosters.com/household/sitemap1.html [Pingback]
http://eofw1lk.net/colorado/sitemap1.html [Pingback]
http://bombaylogger.web.aplus.net/02/index.html [Pingback]
http://bycv3ve.net/bmw/sitemap1.php [Pingback]
http://kiva.startlogic.com/sitemap1.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap2.html [Pingback]
http://gator413.hostgator.com/~digital/babies/sitemap1.html [Pingback]
http://vahq8px.net/internet/sitemap1.html [Pingback]
http://gh9kwkn.net/digg/sitemap1.php [Pingback]
http://hrxc1zr.net/volunteers/sitemap1.html [Pingback]
http://d579737.u108.floridaserver.com/sitemap2.html [Pingback]
http://gator442.hostgator.com/~hockteam/alaska/sitemap1.html [Pingback]

Friday, March 23, 2007 10:26:11 AM (GMT Standard Time, UTC+00:00)
It's interesting that a majority of the elements in this list are non technical.
You can have good developers, good tools, good developement methodology,... (Microsoft probably has all that) and your project can still fail spectacularly.
Saturday, March 24, 2007 11:21:30 AM (GMT Standard Time, UTC+00:00)
Meanwhile I'm wondering how much of the MS OO XML fits into those categories that mark impending failure:

"Trying to do too much in the first version." ? Quite conceivably. How many people actually used its predecessor XML file format, regularly?

"Competing with an existing internal project that was either a cash cow or had backers that are highly placed in the corporate hierarchy." ? I think part of the trouble with MS OO XML is that not enough Microsofties are critical of it. Ie, that it has uncritical backers in the corporate hierarchy.

"Complexity is one of the goals of the project because "complex problems require complex solutions"." ? That seems to be one of the major complaints about MS OO XML from non-Microsofties. And it seems to be quite justified.

Just a few thoughts ... ;(
Wesley Parish
Monday, March 26, 2007 1:31:37 PM (GMT Daylight Time, UTC+01:00)

I don't understand your comment. I don't see that any of Dare's 10 points would apply to OOXML at all.
Most criticism on OOXML I've seen is based on wrong assumptions on what it's supposed to do. So this might be a valid point of criticism: what exactly is using OOXML going to buy me? What can I do with it that I can't just as easily achieve with some other method?

This point of criticism actually applies to the large majority of software products and techniques I've seen. Dare's point of "scope creep" overlaps with it, but it's not quite the same thing: some projects do not even have enough of a scope for creeping to even be observable, while many other projects have a good scope but fail to compare themselves to existing alternatives which already cover the same scope better than they promise to do. (This is fine, as long as there is some other good reason for building the software.)

But does it also apply to OOXML? I doubt it. What I would assume to be the stated goal for OOXML is that it allows allows me, a developer, to process an *arbitrary* MS Office document, picking its elements apart and interpreting them with software, and possibly even modifying the document or constructing one from scratch for consumption by Office, without having to make my software rely on any code from Microsoft - but with the distinctive and serious constraint that 100% Office compatibility has priority over everything else. To a large extent it does seem to meet this goal. Any criticism that fails to take this into account is simply beside the point, as far as I can see.
Wednesday, March 28, 2007 4:58:40 PM (GMT Daylight Time, UTC+01:00)
Words of wisdom.
Comments are closed.