Martin Fowler’s quote is relevant: “You can change your organization or change your organization.” Given that you’ve apparently decided to change your organization (make it better) instead of change your organization (work for a different organization), here are a few suggestions.

First, a lot of your course of action depends on details about the power structures and politics at work. Is there one software development manager, or several? If several, are there any of them who aren’t change-averse? How many software developers are there? Are the developers interested in changing? If so, there are some changes that you should be able to make even without management approval. (As Fowler suggests in Refactoring, you may not even have to tell management. You’re presumably hired to develop software as best you can, so if there’s a better way of doing it, then just do it.)

Second, keep in mind that management may have good reasons for what they’re doing. You’re a software developer; your job is to develop good software and to know good techniques for doing so. Management’s job is to understand bigger picture issues and business considerations that may be beyond your purview. Even if you’re right and they’re wrong about what the business considerations are (your concerns about lack of innovation, late delivery, customer complaints, etc.), understanding where management is coming from will help you communicate in their terms, alleviate their concerns, and so on.

Third (and related), make sure you can speak the language of business. A business is (rightly) not directly concerned with good software development practices; a business is concerned with serving customers’ needs and making a profit. (And many businesses will obviously do the minimum needs-serving possible to make a profit.) You’ll be more effective at promoting change if you can explain how bad software development practices and lack of innovation will hurt the company’s profit or long-term health.

Fourth, changing a company culture from the position of a rank-and-file worker is extremely hard. James Shore (an agile consultant and author) wrote a Change Diary describing his own efforts at doing so. I’d strongly recommend reading the whole thing. A few relevant points:

• Don’t try to change everything at once. Find the biggest pain points and start there. Get everyone on board by helping them to see how your changes address those pain points.
• Understand others’ perspectives. Shore talks about how the changes he was pushing from a software development perspective were resisted by the project manager because he (Shore) failed to consider how the changes would affect the project manager.
• Eventually, you’ll need some support from higher up, even if you’re prompting most of the changes yourself. Shore talks about his champion (“somebody I work with who has more clout than me and thinks along generally the same lines I do”).

The obvious short answer is to leave the company. Others have already left, and your manager is an active obstruction to progress. If you stay in that position you’ll slowly decay (both in morale and skills). Finding a new job isn’t always easy, but in this case it is necessary.

Just in case you chose not to leave the company (the first line of your question kind of gave that away):

Does your manager have a boss? If so, how does that boss view the product? Can you (dare I even say it?) go over your manager’s head and approach his boss? Don’t nag him with technical details, just express interest and enthusiasm in growing within the company. Present tangible ideas for improvements that would measurably affect the bottom line. You might get promoted out from under the obstacle.

Be warned though – while some squeaky wheels get greased, others get replaced. You WILL cause your manager to strongly dislike you. He will hear about this, and he will say unkind things about you to his boss. Tread carefully, but remember – no risk, no reward.

The worst that can possibly happen is that you’ll be looking for a new job, which you should be doing anyway.

Sounds like it’s time for you to learn about cash cows. Go here and here. And take a look at the Growth Share Matrix. The GSM provides some additional information on why cash cow is a good state to be in.

Investopedia (second link) probably has the best quote in this case.

1. A cash cow requires little investment capital and perennially provides positive cash flows, which can be allocated to other divisions within the corporation. These cash generators may also use their money to buy back shares on the market or pay dividends to shareholders.

As you noted, there are some upsides to being on a cash-cow project.

• It’s stable
• A modest degree of new development is guaranteed
• There’s always bug-fix work to tackling.

And as you also noted, there are some downsides to those projects.

• It’s stable and the code base doesn’t turn over much
• New technologies are generally ignored (too expensive to bolt on)
• And things get … stale.

I once worked on a project where I had many similar complaints as what you’ve raised. I distinctly remember sharing my concerns about the code base with my boss at the time. His insight wasn’t particularly enlightening so I won’t share it. But I stuck out the project and truth be told, it was one of the better projects I’ve seen. No, it wasn’t flashy. Yes, we missed deadlines. Yes, I racked up a few death marches from there. No, the code technology wasn’t all that innovative but we did generate some amazing solutions.

The problem was me. I didn’t have enough perspective to understand what a code base really requires in order to survive. I didn’t have the experience to see where the innovation was truly occurring. I didn’t understand the market fundamentals that dictated what the appropriate level of funding was for that cash-cow project.

I would encourage you to see this as a learning opportunity to better understand how business works and how you can improve your skills in adapting a product to the business’ needs. While the work may not be flashy, the learning potential is high and those skills will stand you well later on in your career. The majority of corporate level development revolves around all of the constraints you just mentioned. The code stinks; things were slapped in place to contain deadlines that had already escaped; many developers are resistant to change.

At some point, you’ll still move on from the project. The lessons you can take away with you can be real career making lessons.

I think that this is a really hard problem with no direct solution. Here are some ideas on what you might try doing:

Fear of Change
On the subject of changing things for the better I get why management fears change. People are used to things a certain way and if you change it the users will revolt (maybe). Change is a scary things and usually requires a lot of thought and study before done. What you need is data to show that this is better and that users want it. Speaking of gmail you might look into doing something like “Google Labs” where you could enable/disable new features so that users can give them a try. Then hook up some data collection around this to help back up your changes.

Changing the Software Development Process
Again change is hard people don’t just change because you say there is a better way. I think that in this scenario my best recomendation is to lead by example. Do things that way that you want them to be done and show people how much better it is. Also, and this is key, you need to find the others that share your thoughts. If you can get a few people on board that will greatly help your cause. Once you can show some results then you can approach management about making these changes wider. I find that a top down and a grass roots effort really does help with making changes.

Also on the tools side companies fear upgrading/changing these because they cost money and the results of new tools are not always measurable. My recomendation here is to make your own tools. If you make your own you will save yourself time and do better work. Hopefully people wills start to notice and then want to use them too.

Changing management
This is hard and I am not sure how do it aside from being someone who produces results and has their opinion valued. Once your opinion is valued people may start to listen or they may not.

Lastly remember change is hard and takes time. Hang in there and start small and build up.

Your manager probably is resistant to change because he sees no (business) value is changing practices. The business sees no real problem because whatever is asked of the development team eventually gets done and client complaints don’t make it to the people that care and/or can do something to ensure a better result. Either that or the business has come to accept the current state of affairs as unavoidable.

If you are going to change development practices, you need to show them that the current state of affairs is not unavoidable. And the only way you are going to be heard is by building a business case showing how the current state of affairs is running up the cost of the product and holding back the revenue potential given another state of affairs.

To build that business case you need to be talking to the product manager of this piece of software. The product manager being the person who decides on the priority of items to be developed based on the business value they represent. The product manager is (should be) the one that can see the benefit and business value of being able to build better software more quickly. (And I do hope it is not the same one as is in charge of the development team.)

The business case needs to address what the effects are on business revenue of:

• Features that are not (yet) implemented that would generate more customers or retain more customers had they been implemented.
• Features that are inadequately implemented that generate customer dissatisfaction and lead to attrition in customers.

The business case also needs to show how current development practices are affecting the speed and cost of developing much needed features:

• How long it takes to make even the simplest changes.
• How many bugs are introduced as a result of developing new features, both in the new feature as well as collateral damage in other features.
• How much time is taken up with fixing these bugs that can’t be spent on implementing new features.
• How many support calls are generated because of these bugs and how much support staff needs to spend on these calls.

And of course needs to show how adopting better development practices is going to affect these figures.

You are probably facing the need for a (major) rewrite of (major) parts of the software. Even if you don’t, then How To Survive a Ground-Up Rewrite Without Losing Your Sanity is a must read in how to approach these kinds of projects.

Final note: if the product manager isn’t interested in all this, you’re lost: jump ship.