Product Related Classic Mistakes
Join the DZone community and get the full member experience.Join For Free
As Steve’s book states, classic mistakes are classic mistakes because they’re mistakes that are made so often and by so many people. They have predictably bad results and, when you know them, they stick out like a sore thumb and the idea behind listing them here is that, once you know them, you can spot them and hopefully do something to remedy their effect.
Classic mistakes can be divided in to four types:
- People Related Mistakes
- Process Related Mistakes
- Product Related Mistakes
- Technology Related Mistakes
Today’s blog takes a quick look at the third of Steve’s categories of mistakes: Product Related Mistakes, which include:
- Requirements Gold-Plating
- Feature Creep
- Developer Gold Plating
- Push-me, Pull-me Negotiation
- Research Orientated Development
Requirements Gold-PlatingDefining a luxury Rolls Royce of a product when an economical hatchback is all that the user requires. This is adding unnecessary features or function points. Users tend to be less interested in complex features than either Marketing or Development and complex features add a disproportionate amount of time to the development schedule.
Feature CreepThe average project experiences about a 25% change in the requirements over its lifetime. This will add at least 25% to the schedule.
Developer Gold PlatingDevelopers like to play with new technology and are anxious to try new things out - even if its only as a means to bolstering their CV’s. They also like adding features because they’re ‘neat’ or ‘cool’ and will take no time at all. There’s no such thing as a free lunch, all new features need to be tested, documented, supported, reviewed etc. etc. Add these features in the next release after evaluating whether or not they’re really required.
Push-me, Pull-me NegotiationThis is bizarre! Some managers approve a schedule slip on a project that is progressing more slowly than expected and then add in additional new tasks after the schedule change to make the schedule wrong again.
Research Orientated DevelopmentIf your project pushes the state of the art limits, requires new algorithms, hardware designs and higher speed then you’re doing research not development. Research schedules are very problematic and usually wrong. Beware, don’t expect to advance the state of the art to rapidly.
Opinions expressed by DZone contributors are their own.