>>>>>I agree completely with Rick in this regard. Those backdoor tricks only increase technical debt and will for sure bite you back at one time.
>>>>>
>>>>>Even better try to upgrade the affected data with non-ambigous values if possible.
>>>>>
>>>>>"Always code for the maintener:
>>>>>Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live."
>>>>
>>>>... and of course there is that possibility that YOU might be the poor soul that needs to maintain that bit of code.
>>>
>>>And then he has the benefit of knowing which moron wrote it, and where he lives...
>>
>>In fact yes to the first, but no to the second, because this person has passed away a few years ago and and that had put the company he worked for in a very dire situation.
>>
>>Now I have to assess the debt we are in. Based on past mistakes the company is loosing several hundreds of Euros, at times thousands, on a daily basis. A routine customization which should take maximum one day of work (average speed programmer) takes at least one full week, but mostly much longer.
>>
>>The previous developers have constantly focused on doing something quickly. Now we are focusing on building good design. As the first strategy seems to give you quick results, it very soon becomes clear that you are loosing more and more time, the bigger the application gets. The more thought-through approach seems to be more time consuming in the beginning, but later rewards you with a complete system that will pay you off instead of increasing debt. Overtime has stopped and we are more productive then every before.
>>
>>Also the previous code had to do many late hours and overtime constantly to
>
>
>There is nothing to say against this.
>
>A quick'n'dirty solution like the my_dow function (and the even quicker #DEFINE) are a pain in the end.
>But until then, they earn money. Don't forget, how ever creepy it looks now - there was profit. If the guy would have worked by the book, possibly the whole project might be dead for a decade. I guess some manager was happy about high productivity at those days.

There are indeed different scenarious that need to be carefully evaluated. There are different types of applications: A small tool, or a simple application, that does not see huge growth during the years, on the other hand flagship applications that will become an important pillar of a company for many years. Very often the latter grows exponentially during the years, and when faced with technical debit, the development slows down exponentially as well during that time.

In the application I took over, that happend very quickly, a few years after implementation new features took more and more time, and the number of errors grew as well. Now after starting to clean up around two years ago, the support team is surprised how quickly things can be done now as opposed to before. Every little thing seemed to be a big hurdle and the support team had to send back errors very often.

The quick and dirty often seems to be quick, but in fact it isn't necessarily. What I see is, that the developer is not willing to adapt new Knowledge or to go out of his or her comfort zone. Of course at first when trying to implement new strategies there is a learning curve and it seems to take more time. But very soon after practicing and learning, you can write better code as fast as you did before. There is no law that says that good code takes really much more time.

Now there is always a balance between the puristic "Right" way of doing things, and to be productive as well. The opposite mistake would be to overdesign every little element and to try to solve problems that don't even exist. When doing that you will indeed loose a lot of time and there is no reward in spending those kind of hours. Experience tells you how far you need to go in a certain task.