A couple of years ago the Standish Group published a revision of their famous "chaos" report indicating that things in our fair profession had gotten much better between 1996 and 2007. The number of "successful" software projects had moved up to a stellar 35% from the earlier 16%, and outright "failures" had reduced by a similar margin, from 31% to 19%, leaving the rest, around half of all software projects, as "challenged" (1). I would guess that our tendency to think well of our works would exaggerate the positive numbers, so I'll bet the "real" numbers, if there were such things, were lower. More on that below... (And it looks like the numbers are worse again in 2009 according to this year's report. (2))
OK so 35% is not a very impressive number, so software development must be hard. But despite those numbers, there are plenty of us who consistently ship software projects that objectively could be considered "successful." (I.e. make big money, win awards, etc.) Successful software projects are not evenly distributed throughout the industry, so how does one get on the right side of those numbers?
That's a daunting question, one that I can hardly begin to touch in a blog entry. I'm guessing a Steve-McConnell-Book-Length is about the right size to cover it, and Steve does present a lot of helpful material. However, the bibliography for getting good commercial software out the door does presently seem to leave many important topics uncovered: how to tell if a bug is "stop-ship," how to know when that API is really ready to freeze & publish, how to tell if that nagging user is a gift from God or a time-sucking servant of Satan? (Hint: if it's me, remember I'm always a gift from God and your best friend besides. Now fix that damn UI the way I told you...)
I believe development is mostly a teachable skill to people near the top of the talent range. Having played this game a dozen times with a few hundred software developers, I believe the number of candidates who could contribute to a successful software product is around 15-20% of the overall talent pool, including what I call "high intermediates" and "advanced" candidates. Daunting as it is, there are ways to win the software project game and avoid the more common chaos.
However, there is another factor in software product development, and that is the product. Getting a successful software project completed is hard, but doable. However, creating a successful product is a true dark art. I think the distinction brings us back to the Standish Group and a discussion about how we measure success. Software is soft, so it allows us a lot of leeway in how we define the boundaries between success and failure. Shipping a successful software project involves getting a bunch of not-very-objective people involved with a project to agree on the criteria for success, then fulfilling that criteria. However, shipping a successful product involves getting a bunch of uninvolved and indifferent people to agree you were successful in the form of giving you their money. That is a much higher bar, and it's only to be expected that far fewer software projects become successful commercial products. You can define your own criteria for success in a project, but there's nothing forcing the rest of the world to agree with you that your product is any good.
(1) http://www.sdtimes.com/content/article.aspx?ArticleID=30247
(2) http://www1.standishgroup.com/newsroom/chaos_2009.php
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment