I think one of the hardest things in a support project is both ensuring consistency with your collegues when coding anything, not to mention consistency within an existing application itself.

The problem is every developer has different ideas on which way things should be done, and enforcing those standards is one of the most difficult tasks for management among a team of (usually) very independent developers.

I find it quite amazing (and not always in a good way) how often we as developers shoot ourselves in the proverbial foot in regards to these sort of things, especially when we are in a hurry, or worse, are completely convinced of our own self worth, ignoring the conventions set forth by the previous devs - simply thinking 'I will do it a better way'. Sometimes the best way isn't necessarily the best way...

From an application support standpoint this sort of thinking is terribly dangerous, and I can attest firsthand the sort of pain a glaring lack of consistency can cause. Unfortunately, the 'I can do it better' mindset usually results in a developer either overcomplicating the section, or even worse, simply getting it wrong (and in extreme circumstances an unnatural, hideous combination of both).

Coding standards are there for a reason, so the next time you are developing a section of an existing application and you are considering breaking away from consistency, just don't. Have a serious think about what you are doing and quite possibly how your changes might affect other parts of the application, not to mention your collegues on the front line, battling the already existing consistency break-aways from devs beforehand.

After all, you don't want to give anyone a stomach ulcer from dealing with your code...

Do you?