When it comes to developing software, there are always trade-offs. Do we want to release the product faster and risk more bugs, or slower with less bugs? Do we want to provide customers with the features they want – or just with basic functionality but more robust. This comes down to what importance we place on the following objectives (suggested by Steve McConnell).
- Minimal defects (defects=bugs, not missing or incomplete features)
- Maximum user satisfaction (providing all of the features they want in an easy to use way)
- Minimal response time (ie fixing bugs and getting new features developed faster)
- Good maintainability (low risk of breaking stuff when making changes, the ability to make changes faster and introduce new developers faster)
- Good extendability (making software soft – ie basing core business functionality on a rules engine, or basing the UI on a forms engine)
- High robustness (no crashing, no loosing data, good performance, you trust it)
- High correctness (the lack of missing or incomplete features – getting your requirements right in the first place so you build the right thing)
While some of these go together, most of them are trade-offs and its an interesting exercise to get everyone in your company to rank these from 1 to 7. Because they all trade-off – you can’t put any at equal priority and whatever you put at priority 2 – you are saying should be sacrificed where necessary to achieve priority 1, and priority 3 should be sacrificed where necessary to achieve priority 2, etc.
How you rank these will be specific to the priorities and values of your company – but also to the specific product you are working on.
Currently – not taking into account any specific products, my priorities are in this order:
- High correctness
- Good maintainability
- Good extendability
- High robustness
- Maximum user satisfaction
- Minimal defects
- Minimal response time
By first focusing on your business and user requirements, architecting for extendability and coding for maintainability – you can give your product a strong base – and then almost forget these aspects and focus on robustness and user satisfaction.
31 October 2007 at 2:10 pm |
[...] and IronRuby are that they give you fast results now, but at the cost of maintainability later (since everything’s a tradeoff). But, maybe maintainability doesn’t matter so much, because its faster to just re-write [...]