Thinks...

the software development life cycle

Thunk on or about 18th August 2005

One of the things you are likely to be asked in a programmer job interview is your understanding of the SDLC. If you don't know that this stands for Software Development Life Cycle you are right behind the 8-ball. If you do, you probably know enough to wing it.

There has a great deal of dubious material on the SDLC - much of it, I am convinced, written by people who have never actually developed any software. The following is what you might call a worms-eye view of the process.

Phase 1: Requirements Gathering

  1. receive vague 3-line description with request for time/resource estimate plus or minus 100 percent
  2. pull number out of the air and double it
  3. receive 5-page specification with request for time/resource estimate plus or minus 5 percent
  4. discover page 1 is the title page; page 2 is the table of contents; page 3 is the executive overview and page 5 is the document change log. Actual specification consists of a vague 3-line description on page 4.
  5. take the number you first thought of and multiply it by the length of your desk divided by the width

Phase 2: Detailed Design

  1. hire consultant who knows nothing about your products to produce a functional specification
  2. review late-arriving functional specification and reject it as inadequate
  3. discover the project manager has accepted the functional specification because the budget can't afford to keep paying the consultants
  4. start a detailed design of the software based on your best guess of what the spec means
  5. discover you don't have time to implement this design because, not only was the spec late, but the test phase has been moved forward

Phase 3: Development

  1. hack together a quick solution
  2. try to get clarification on those parts of the spec which are logically impossible
  3. update the hack
  4. rewrite the hack on the basis of the updated design spec which has just arrived
  5. discover test release date has been moved forward again
  6. work all weekend to remove the more obvious bugs and release into test

Phase 4: Testing

  1. do another test release to fix the new bugs introduced by everyone being too tired to think properly
  2. fix more bugs
  3. release to test
  4. repeat steps #2 and #3 until the weekend before the production release date

Phase 5: Operation and Maintenance

  1. work all weekend to remove the outstanding bugs then release into production
  2. do another production release to fix the new bugs introduced by everyone being too tired to think properly
  3. push out a rapid series of releases until the software more-or-less works properly

Phase 6: Post-implementation Review

  1. before the meeting, make a list of why it was everyone else's fault
  2. throw away the list because the meeting has been cancelled

What got me thinking about programmer job interviews?

Dunno really. Just one of those things that pops into your mind every so often.

date

last updated
time