More reasons that software estimates are inaccurate
Posted by robkraft on May 11, 2010
One source of inaccurate software development estimates is the residual impact of a new feature. On a recent project we decided that we wanted to persist the user’s column width customizations in the grid of our Silverlight application. We estimated that we could complete this in just two hours, so we did so. However, after we implemented the feature we realized related issues that needed to be addressed and thus all took additional time. Some of these issues were:
• Will the customizations persist if we release a new version of our code?
• What happens when a user resizes the entire form and grid? Is that the behavior we want?
• What happens with a grid designer adds or removes columns from a grid that a user has saved customized column widths for?
• Should we have tied the customizations to the grid id or to the form id the grid was displayed on?
Residual issues and questions like these often show up during the development and testing of a new feature and are not accounted for in the original estimate. Some of these can be resolved in less than ten minutes, but others may take much longer.
What does this mean to a development team? Just that several people should generally be involved in the decision to implement new features and that a few extra minutes should be spent up front to identify as many issues as possible if you desire the implementation time required to be close to what you expected.