.. becomes muddy and sticky. The AbapcadabrA authors point of view: when developments are done in limited time (which is always), the quick and dirty approach tends to present itself.
"Worry about the not too important stuff later"- Later is often enough never.
"Don't fix it until it's a problem"- All we seem to be doing is fixing problems.
"The fix was really small, finding out where to put it was very time consuming"- A clear sign of spagetti coding.
Any development or change to development can be split up in different parts. A typical small development change would involve finding the problem, performing the change, adding the change to the comment header of the program and creating the transport (with description). Updating the technical design and of course testing (unit testing) the change is also the developers task. What should the developer do when he/she stumbles across a potential performance issue ? When only a quick fix was planned, the performance issue could produce a lot more work than the initial fix.
When Quick and Dirty changes are done - the potential performance problem will never be solved. Only when the actual performance is reported as a problem, a quick and dirty fix can be applied to the development. The overall development will become a gathering of quick fixes - which tends to grow like an aggressive tumor.
When the developer is asked to perform a change or fix to a program, he/she should "take ownership" of the program. When the package is delivered - there should be nothing wrong with it. It's a bit like taking a car to the garage for new wind-screen wipers: if the engine was placed the wrong way around, you'll get a phone call informing you about the engine. You yourself are not the expert on cars - and you can trust the garage technicians to deliver a car in working order (or at least they can inform you it's not likely to work).
In some cases this means a program should be overhauled completely - if there's no time for this, do make sure the end user learns about the state of the program.
The garage technicians will have a set of "minimum demands" a car should answer to. On any development project - there should be naming conventions and programming conventions which describe the minimum demands on any development. A few examples:
- Database updates should be locked
- Performance rules apply
- Authorization checks must be available on reports or screen modules
- ...
Initially this could present development overhauls for quite a few developments - on the long run the developments will become "stable" and quick fixes will disappear..
Thus: whenever a development has passed my desk - you can expect it to be up to date...
The cost aspect ? The developer will need more time to overhaul the program - time that is saved on changes that would otherwise be done afterwards (potentially by another developer).