Yesterday I posted about Refactoring and Design
quoting heavily from Martin Fowler's book Refactoring: Improving the Design of Existing Code
The same two page section on 'Refactoring and Design' contained even more great insights that I want to share with you on flexibility in software.
"Before I used refactoring, I always looked for flexible solutions. With any requirement I would wonder how that requirement would change during the life of the system. Because design changes were expensive, I would look to build a design, that would stand up to the changes I could foresee. The problem with building a flexible solution is that flexibility costs."
I think this is really on the money. I'd love to quote more from Martin directly but I fear copyright infringement, so I'll explain why.
The cost of flexibility can be large - it takes longer to write, longer to test and it's harder to maintain. However, the investment in a flexible system is rarely fully returned. Once again, refactoring and unit tests make it easy to make the changes when you need to
Furthermore, such flexible systems are rarely properly tested. Take this contrived example: Mr Programmer codes an application to fulfil specification A and adds code so that it can also support some functionality B and C in case it is needed in the future.
But these facets are never tested - the testers test against specification A, but not B or C, at which point the code is shipped. Sometime later, Mr Consultant finds and uses functionality B (great, some ROI on our flexibility) assuming it has all been tested and works (oh, maybe not so great).
Some who know me may think this post is slightly hypocritical, as I love extensibility
in software. Imagine Visual Studio without Add-ins or Reflector
without plug-ins. As usual, it's a question of balance. Just make sure your requirements for extensibility are part of your design.
05 Apr 2006
» Next Post:
ThreadPool Settings in machine.config
« Previous Post:
Refactoring and Design
Comments are closed for this post.
05 Apr 2006
I don't think extensibility is a counter-example to this principle though. Ideally, you would not implement an extensibility model without several concrete extensions to implement.
I would hate to try and use a plugin model that was developed without any actual plugins to guide it.
06 Apr 2006
I totally agree with you and I probably should have made that clearer in my post!