Monday, November 2, 2009

The Rest of the Product

We have a test plan, and it's great. It covers all the features, and all the workflows of the application. We've got stories, we've accepted them. We've written some automated tests.

Congratulations, you're now half done with the product.

The product is not useful until you can actually use it in production. So now that you've built the darn thing, it's time to think about:
  • What's production going to look like? How many machines? What configuration?
  • How are you going to get the software into production?
  • How about the config info? How're you going to go from dev to test to prod? (hope it's not hard coded into the war file or rpm somewhere!)
  • Okay, once you got it into production, how're you going to start it?
  • Come to think of it, how're you going to stop it?
  • One day you're going to have to maintain this thing. Got a plan for that? Is down time okay? Can you do some rolling upgrades or maintenance?
  • How are you going to see what's going on? Got logs? Got a way to get logs back to dev for analysis?
  • How will you know it's running? Any monitoring? Notifications?

There are a lot of questions to answer once you've done the basic implementation. Don't forget to include those when you're thinking about testing it, too.


  1. "So now that you've built the darn thing, it's time to think about:"

    I would say that this should be discussed before a line of code is written.

    Then, once you have a "Hello World" application, get that up on a live server, start it, monitor it, etc.

    I.e. fail *early*!

    Deployment, and its planning, shouldn't be saved for the tail end of the process.

  2. I agree. Deploy early and often (at least to test) is ideal. It doesn't happen as often as I'd like, though. So often it's easy to say, "well, there's nothing to see yet" and put it of until after we've built the next feature.

  3. It appears that "Walking Skeleton" is the metaphor used to describe this approach: