Thursday, May 1, 2008

Intelligent Feature Design

So I'm working on a critical high-visibility project that is aiming to be deployed in seven months. It's an app that will only be deployed for 3 months a year, and after we deploy it this time, we'll be working to add more features for the next deployment. Most importantly, we have a "GO-NO GO" date (like rocket launches) in 4 months where we make the call if we're going to be able to deliver the product.

One of the features requested is the ability to change the instruction text in the app on each page from year to year. My first thought was "We can push that feature to next year since we're going to be working on it then, and we'll just hard code the text this time." I said this to the project leader, and he insisted we should do it this time around: "It's just 'select *', that takes like 10 minutes, right?" Well, it's not just that:

  • Modify data file to include this text.
  • Get text from database into the file.
  • Add code to the app to read this specific text and change the labels. 

Now, this is pretty much a 4-hour feature. And he's probably right that adding this feature will not affect the ship date, and we'll still be "GO" in 4 months. But why risk it? 

The project leader countered with institutional knowledge: "We have applications from 10 years ago that we still have to redeploy to change text in them. That's a waste of developer time." True, but the lesson learned here is not the correct one. Why haven't we spent the time to fix these apps? We're already committed to development on this app after the deployment, so why add any risk now? 

I'm not the first and I won't be the last person to mention risk and features in the same sentence. But this goes back to the sentiment I express the most: Be smart. The feature in question is on the feature list, but it'll be the last one I develop. 

No comments:

All rights reserved. Take that!