« The Leopard has landedLolNimble »

Software development: five easy ways to fail

11/04/07 | by Adam | Categories: Technology

Link: http://www.inc.com/magazine/20071101/how-hard-could-it-be-five-easy-ways-to-fail.html?partner=fogcreek

Good article from Inc.com by Joel Spolsky of "Joel On Software" about common ways that software projects crater. Some comments on it are below the fold.

One of the most revealing statements is this about estimating cost and time for a project:

But software developers are building things that they've never built before. If they had, they'd just sell you another copy of the CD-ROM. So rough estimates are impossible.

He's right; for most software development work, unless it comes shrink-wrapped, it's custom and it's new. My personal experience is that when a potential customer comes to you and says "We want your off-the-shelf software as we don't want the cost of maintaining a customized version", you just know that five minutes later the following sentence will be spoken: "Oh, we need you to add this and alter this as the software doesn't quite fit our business model." And that's where things start to go to slower and more expensive. This isn't the focus of Joel's argument -- he's of the opinion that weekly goals are too long when it comes to development -- but the content of the quoted sentence is perfectly correct.

A bit later on, Joel says this:

That's because when one developer steps in to replace another, it's reasonable to assume that the new one will work at about one-tenth the speed. John's going to have to spend untold hours figuring out all the things that Mary already knows about her area of code. And John can't fix Mary's bugs as fast as Mary can because Mary knows where all the hidden traps are.

Again, this is borne out by my personal experience. When I've assigned developers with free time to resolve outstanding problems in another's area of expertise, inevitably the latter will be finished before the former's up to speed meaning that if I'd waited, the problem would have been fixed sooner and I'd have had a person to put on something more appropriate to their skill set. There's definitely an argument here for cross-training but for that you need to have a surplus of money, time and developers, and that's a remarkably rare situation.

Finally, he covers the issue of burn-out. Games companies like Electronic Arts are notorious for pushing their staff hard. They tend to have short schedules, specific release dates they have to hit where sales are highest, and management who think of their staff as "resources" rather than people. They can afford to regularly lose their experienced developers as each game is another chance to start over; it's very rare for code to be reused or supported after release. As such, experience and domain knowledge is nice, but not required. At the other end of the scale you have corporate IT systems or commercial applications where it is essential that these people stick around. Best way of doing that is by frying them on what Edward Yourdon refers to as a "death march". Joel's comment here is that overworked people don't deliver good code. He's absolutely right.

(Via Joel On Software)

 

No feedback yet

November 2021
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
"Ready, Aye, Ready" was a slogan used by Canadian politicians to indicate Canada's willingness to assist the British Empire in any conflict. It remains in use as a motto for some of the Canadian military. It has almost nothing to do with the content of this blog.

Search

  XML Feeds

blogging tool