We have a small team (2-3) of programmers writing a program with a lot of forms and dialogs. We have a problem where we cannot keep good consistency in what we write, or how we write it.
The latest issue I've noted is that we have lots of places where we have a date range, and we use all kinds of wording to indicate this range is it Start/End or From/To or "Between _ and _".
The other side of this is that one of the developers might come up with a better way of doing something (like maybe initializing the state of a check box from the settings file). And then we'll have all of the "old" stuff written in the old/poor way, and new stuff written in a better method.
I try to be constantly vigilant about the first thing, but it seems like I'm always finding new failures.
The second one creates a huge burden if we're going to go back and fix all the old stuff as soon as we come up with a slightly better way of doing something. Either that, or we ignore all old stuff until something is broken, and then we have no clue what the heck the software is doing because its written completely differently than what we write currently.
One last thing, if we push the burden of "fix it everywhere now that you've found it" on the developer who comes up with the better solution, its self defeating, because its like great, that's a better way to check for that error, now fix it everywhere in the code.
Bosses don't really ever seem to care about the quality of the code, just when we'll be able to release the next version (but that's a different discussion).
Best Answer
The most important thing for you and your team should be communication.
You might want to develop a common styleguide that defines things like "how should a date range be named". However it's very important that this styleguide is appreciated by everyone on the team. If anyone has the feeling "oh my god, I know how to do my work and now I have this stupid document telling me what to do" then the effort is doomed from the beginning. On the other hand if everyone agrees "yes, that's a good idea, now I know where to check when I don't know how to name a thing" then you'll be a lot more productive.
However such a common belief is established best, when everyone is part of the development process and feels like "yes, I contributed to that set of guidelines". If your programming team is small, as you wrote, then it's the ideal situation.
The other fact will hunt you for the rest of your development life: You will never ever write perfect code. That's been said alread. But you will never ever write code, that when you're revisiting it a few weeks later will still look good to you. Even if you're the only one having touched the code. I always find myself thinking "my god, what the hell have you been thinking when you wrote that piece of crap?". The funny thing is: I know, that I had my reasons for doing something in exactly the way I did - I just can't believe it any more.
You have to accept it, and yes, it get's worse when you're working with somebody else because - let's face it - writing software is like driving a car: nobody can do it better that yourself ;-)
So, you will always have to refactor your software. Fix the things you did wrong in the first place. That's a good thing and totally normal.
That may be true on first glance. Luckily not all bosses think that way, but even if they do: Code quality has a direct effect on the ability to ship the next version. Bad code leads to more bug, leads to more time needed to fix the product, and so on. The central element here is communication - once again. You have to embrace the thinking that refactoring and introducing better code is an integral part of the development. Refactoring is not just "Oh, this looks better, let's take some time and implement the change" but making the product fit and robust for future generations. This might require some backbone telling another person "No, we can't move on, we need to refactor feature X" but that's part of the job.