[acron0]

For me, this is something that has just gotten better with experience and practice.

Of course, we all start out with a clear and rigid vision about how the code should be - you use good design patterns, you let your data dictate the flow of your code and inevitably, some scenario comes up that doesn't play into your structure well and you concede a hack. Then a couple more. But with experience comes being able to identify areas that are more likely to attract smelly code and thus you are able to prepare in advance.

One of the paradigms that I am always reiterating to my team is that their code only needs to be 'good enough' and of course, this is relating to productivity. It doesn't need to be the shiniest example of a memento implementation I ever saw - first and foremost, it needs to work. And it needs to work when I need it to work, not 2 weeks after because you just had to refactor it just one more time. This is the reality of being a professional developer, working with customers.

[xackpot]

Fair enough. I agree that the code has to be working but sometimes, even after laying down the guidelines on how to write code a better way to structure out, things go out of hands with multiple contributors. In my opinion, the solution to this problem is to refactor the code as soon as the code is checked in. Not necessarily refactoring the whole code, but to make it conform to the existing design and structure.