If it ain't broke don't fix it
| Line 6: | Line 6: | ||
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. | 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 | + | The idea is short sighted if followed without question. For the long term, fixing working code now may well be worth the cost. From OO standpoint - BAD. |
== Conflicts == | == Conflicts == | ||
[[Refactoring]] - the quality of code should constantly be improved. | [[Refactoring]] - the quality of code should constantly be improved. | ||
Revision as of 09:27, 12 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 OO standpoint - BAD.
Conflicts
Refactoring - the quality of code should constantly be improved.
