Notebook
October 6th, 2007 by Jilles

Kyle Wilson wrote recently a really nice piece on why software development is so hard, which for me didn’t include new insights (I’m already convinced) but did a really nice job on quantifying the problem space. Something which I had not seen before so clearly articulated. If you’re in this line of business, it’s a must read.

The thing that makes this article so interesting is that for some reason Kyle has access to information about five large software development projects: Chandler (the OSS Exchange replacement), Myst Online, Fracture (a new game), the software that controls a F-22 fighter jet and the FBI’s Virtual Case File.

After describing some of the pitfalls the Chandler team fell in, he goes on trying to outline why Lines of Code (LOC) is a useless metric for determining the complexity of a software program. More importantly, he throws in some statistics of the aforementioned projects that really hits this home.

Short list of conclusions:

• LOC is useless as a means to describe either the complexity of the program or the amount of effort that went into producing it
• Project teams need an economic framework (in the broadest sense of the word) in order to be successful. Otherwise there is no forcing function for decisions (like design choices, feature sets and release dates).
• In theory the complexity of a well-structured program should be O(n), where n is the number of lines of code (each line only tightly coupled with the line preceding and after it). A poorly structured program would be O(n2), with dependencies on one particular line throughout the codebase.

Favorite quote, from the 1968 NATO Software Engingeering Conference: “We undoubtedly produce software by backward techniques. [...] We build systems like the Wright brothers build airplanes — build the whole thing, push it off the cliff, let it crash, and start over again”.

And this one: “Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves” — Alan Kay (the father of Smalltalk).

Related posts:

  1. Software development project management Just ran across the site off Basil Vandegriend, who wrote...
  2. Database versioning techniques Today I had an interesting discussion with one of my...
  3. Some good articles about product development and product management A long while ago, Joel Spolsky added a Reddit.com site...

One Response to “Software development is hard”

  1. No shit… That’s the only reason why I use OpenBSD - no bload, but small and solid-build software. Generally, it’s very difficult to write a stable state machine, let alone test it completely with 100% coverage. Actually, testing can be considered half-done once you know what to test ;)
    The main art is, of course, to build software that
    a) can be written correctly
    b) can be tested fully
    c) does what the user wanted…

Leave a Reply