The way that some people go about the task of developing software, you'd think that the primary activity was typing. This is made evident by voluminous amounts of ill-considered code that is both brittle and rife with duplication and kludgery. As the size of such a code base grows over the years it becomes increasingly unwieldy and convoluted, the result of which is a snarled mess that is damned near impossible to negotiate. Change becomes a painful and risk fraught proposition. Development slows to a crawl.

Integral to any good software development process is that of refactorization. When implementing software it is an incontrovertible fact of life that you are going to make design mistakes. You must accept this. However, if you can go beyond just accepting this and also proactively set about resolving these mistakes, then you can prevent them from compounding and piling up over time.

To this end, you cannot always be obsessed with creating new features. You must also allocate time to pondering where you are, how you got there, and what you can do to solidify and simplify your present code base. This gets back to my original point... Developing software isn't just about sitting at a keyboard and banging out code. Rather, it is an intensely political process, one that involves extensive communication and negotiation. Engaging in such coordination efforts means less time coding, but the time you do spend coding will be more productive, more than paying back your investment.

So, to this end, you must make refactorization periods a regular component of your development cycle. Of course, this also entails that you must have an excellent automated regression testing framework. You cannot have the boldness to refactor your code as needed without the knowledge that you are not breaking functionality as you do it. Creating such a framework is a lot of work, but it's something that you really ought to have anyway.

Being able to refactor effectively when you're on a team of several developers also requires having good documentation. Refactorization involves detecting duplication in code, and said duplication is difficult to find if you must manually scan your entire code base. Instead of reading code, you ought to be able to locate such duplication by performing a cursory scan of high level module documentation.

This won't be easy. In fact, it may be quite hard, as you are recognizing. Some people are stuck in their ways, and other people take no pride in their work, merely wanting to collect a paycheck and go home. As such, if you want this to happen, you may very well have to be the spearhead. Good luck. On the plus side, if your execution is good you may win serious brownie points with management for being proactive.