If it ain't broke don't fix it
(New page: The concept that any working solution is a good solution. Mitigation of effort.) |
|||
| (4 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
The concept that any working solution is a good solution. Mitigation of effort. | The concept that any working solution is a good solution. Mitigation of effort. | ||
| + | |||
| + | == Considerations == | ||
| + | The concept is practically relevant when working under budget, workload and time constrains. It suggests efforts should be focused on completing the missing parts of a system - output further deliverables instead of altering already functioning code. | ||
| + | |||
| + | However, the idea should not be used as an excuse to circumvent refactoring poor designs. For example, if a module of critical importance is poorly designed, interfacing with it may force more bad code to be written, which in turn has the same effect on its own future extensions - a chain reaction. | ||
| + | |||
| + | The idea is short sighted if followed without question. For the long term, fixing working code now may well be worth the cost. From a purely OO standpoint the idea is bad. A practical compromise might be to apply [[Sweeping it under the rug pattern]] as suggested by Foote in [[Big ball of mud]] - cover up that which looks bad behind a usable interface. | ||
| + | |||
| + | == Conflicts == | ||
| + | [[Refactoring]] - the quality of code should constantly be improved. | ||
Latest revision as of 07:25, 20 October 2010
The concept that any working solution is a good solution. Mitigation of effort.
Considerations
The concept is practically relevant when working under budget, workload and time constrains. It suggests efforts should be focused on completing the missing parts of a system - output further deliverables instead of altering already functioning code.
However, the idea should not be used as an excuse to circumvent refactoring poor designs. For example, if a module of critical importance is poorly designed, interfacing with it may force more bad code to be written, which in turn has the same effect on its own future extensions - a chain reaction.
The idea is short sighted if followed without question. For the long term, fixing working code now may well be worth the cost. From a purely OO standpoint the idea is bad. A practical compromise might be to apply Sweeping it under the rug pattern as suggested by Foote in Big ball of mud - cover up that which looks bad behind a usable interface.
Conflicts
Refactoring - the quality of code should constantly be improved.
