If it ain't broke don't fix it
| 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 = | + | == Considerations == |
The concept is practically relevant when working under budget, workload and time constrains. It suggests efforts should be focused in completing the missing parts of a system - output further deliverables instead of altering already functioning code. | The concept is practically relevant when working under budget, workload and time constrains. It suggests efforts should be focused in completing the missing parts of a system - output further deliverables instead of altering already functioning code. | ||
| Line 7: | Line 7: | ||
The idea is solid though a bit short sighted. Long term, fixing working code now may well be the best choice. | The idea is solid though a bit short sighted. Long term, fixing working code now may well be the best choice. | ||
| + | |||
| + | == Conflicts == | ||
| + | [[Refactoring]] - the quality of code should constantly be improved. | ||
Revision as of 06:23, 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 in 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.
The idea is solid though a bit short sighted. Long term, fixing working code now may well be the best choice.
Conflicts
Refactoring - the quality of code should constantly be improved.
