Why are developers averse to maintaining software? They quit at the end of a project or leave if they find they are doing maintenance?

Question

I’m the manager of a department with a tech team that has a high rate of turnover and I want to dig into the reasons for that. We have had 40 developer in the past three years (funded team size is 12) and they stay on average about 4-9 months.

One of the things I noticed going through the departures was that the end of a project often lead to a mass resignation and that developers in the Maintenance group didn’t last anywhere near as long as the developers on the Solutions (custom development) group.

Some Googling told me that maintenance is considered a crappy job for a developer. One guy said that it is viewed as as janitorial work.

Why is this? Is this normal in the tech industry?

Answer 1

I would be very reluctant to do a job which was mostly maintenance. Here is why:

1. It is bad for one’s career (internally). Heroic efforts to keep software working are almost never recognized as people only see the status quo. Someone who stayed up all night to complete a new feature will receive a lot of praise. Someone who did it to keep the software from going down? Nobody even knows they did it. In my admittedly short career, I have never seen praise for good maintenance work. Heard a lot of maintenance/IT people complain about being underappreciated though and for the most part, they are. Ask yourself, what does your senior management think about the support developers? Do they know much about the support developers? Who got praised?

2. It is bad for one’s career (externally). A friend of mine is a very senior developer and for two years, he primarily maintained this large application. He was consistently asked in future interviews why he was just tweaking, not building. Maintaining is not considered to be engineering by many. You see this in many areas outside engineering as well. When I was applying to university, the trendy thing to do was to found a charity and build a school. Why not join and build an existing one? You wouldn’t get credit for it, as even if they achieved the same result as it involved no “leadership” or “initiative.” People who build something are given much more respect than those who keep something working, even if the latter is harder.

3. It’s bad for one’s career (technology). Maintenance projects are more often built with older technology. Problem is, technology has a short life in software development. If you are working on a project with JQuery instead of React or one that uses Ant instead of Maven, Ruby instead of JS, your market value is withering. If you are using AngularJS, Bootstrap 3, Java versions less than 8, Objective C, etc your options become more limited with each passing day as not much new development is being done in these languages.

4. It is more difficult. Today I solved a bug by adding a check and deleting the table in the database. My project is a greenfield which has yet to go to production, so we don’t need to maintain backwards compatibility or keep the existing data. Fixing that bug while maintaining the data would require either running a script to remove certain rows or modifying the API to select the correct one.

5. You are forever a cost center. One advantage of a greenfield project is that it allows executives to get involved and it makes them value the project more. I met these two mobile devs at a conference who developed and maintained an app in Xamarin for cross compatibility. Then there was talk of cost cutting and outsourcing the maintenance of the app to India (I live in Canada, so the cost is substantially different) and saving two dev salaries. Know how they saved themselves? Talking up “compatibility problems” and convincing management to have them rewrite the app from scratch in React Native. That saved their jobs and got them raises. If they are smart, there will be more “compatibility problems” and a need to rewrite in Flutter.

Answer 2

Time for a frame challenge: this issue isn't devs hating maintenance; the issue is that they hate working for your company.

I don't think you realize just how insane your turnover rate is. Average IT turnover is 13.2% per year - and that statistic is framed as a "Holy cow, 13.2% is high!" I worked for a PoS company for awhile, and it had a turnover rate of a little over 20% - and I personally view it as a churn factory. So what's your company's IT turnover rate? About 80%! That's six times the "Holy cow, IT turnover is high" rate, and almost quadruple the "churn factory" rate. (I almost want to copy-paste this entire paragraph in a second time, just to emphasize how dysfunctional this turnover rate is.)

So, I want you to put yourself in the shoes of a developer that has joined your company - and likely hates their new job. They already want out... but they've got a dilemma: do they jump ship after only 2 months on the job? While understandable, it'd still be a bit of a red-flag on their CV that they'd rather avoid. But they're currently working on a project. Maybe the right solution is to simply stick it out a few more months until the project is finished, and then get to claim the accomplishment on their CV? Plus, finishing the project serves as a great 'bookend' - a closure piece that mentally marks their time at the company. There's a very good chance that you're getting mass exoduses after project release isn't because they all spontaneously wanted to quit at the same time - it's that they'd wanted to quit before that point, and were simply waiting to finish the project.

Looking over your question, I think you made a leap you shouldn't have: that they're leaving specifically for maintenance reasons. Have you asked the people that left? Have you asked the current maintenance people for anonymous feedback? Have you looked through glassdoor reviews?

Don't get me wrong: they could indeed be fleeing because they hate maintenance. But there might be other reasons - reasons you're missing out on because of a hasty assumption.

Answer 3

A developers job should be a combination of both maintenance and new project work. I've been doing this for 35+ years. This is common and very misguided.

This type of turnover is an organizational problem. All developers should have a combination of fun, exciting project work (the newer stuff) and maintenance work (keep the lights on).

In my current position we look for a 60/40 split between project work and support work. This can (of course) fluctuate depending on the project and the amount of support.

Companies that don't reward support work to the same extent as new stuff tend to run into issues. When the experienced people leave a wealth of business knowledge along with system knowledge is lost (the bus factor).

Answer 4

Change the question. Instead ask, why do authors prefer to write new books instead of edit other people's books? If you look at it that way, the reason programmers prefer new projects should be obvious. Programmers are creators by nature.

But I want to bring up a minor frame challenge here because I see a pretty big red flag. If your developers are staying with you only 4-9 months, you have a significant problem that goes beyond simply new code vs. maintenance. Are you sure there's not some toxic element in the environment? Or perhaps the code is being slapped together so carelessly that the maintainers don't want to take responsibility for it? Is your project management obnoxious and pushing unreasonable deadlines? 4-9 months is an unusually short average tenure, even in this profession.

One thing you might want to look at is getting rid of the idea of having a 'new development' and a 'maintenance' group. The developers making the 'new' software should be the ones maintaining it. That's how developers grow - they get feedback on work they did, and have a chance to improve it and learn from the experience. All the developers should be involved in both new development and maintaining their previous work.

Answer 5

I can only speak for myself, but the reasons why I'm sometimes a counterexample may be illuminating.

Maintaining a project massively burdened by technical debt can be difficult, but it can also be extremely rewarding. Inheriting disastrously botched Android and ASP.NET projects taught me more things than I can count about what not to do in these frameworks. I've applied these lessons in my own greenfield projects. I've also become skilled in refactoring, which is very valuable in this industry because there are so many projects out there that are collapsing under technical debt. And it's emotionally rewarding in that fixing bugs makes you a hero to the users.

This was all possible because management, or at least my immediate supervisors, recognized that I was dealing with technical debt and gave me a letter of marque to pay it down. Feeling like a hero becomes an incentive when developers know or have some kind of engagement with the users. I've built a very successful career on cleaning up other people's messes, and I can honestly say that I enjoy it. But I can easily see turnover becoming an issue if these conditions were not met.

Answer 6

I don't know generally, but I can answer for myself.

(In no particular order)

1. Projects are viewed as more "exciting", in the sense that they offer more challenge. Greenfield(i) projects especially, as the tech is invariably new(er) and offers more opportunities for learning. Maintenance is the same old, same old.

2. Projects usually have a fixed end, or are done in phases. Maintenance is seen as a never ending list. A month from now will be no different.

3. Project base work can often look better on the CV. "Why did you leave?" - "End of project", sounds better than "I was bored after 2 years of the same stuff". The hirer will note "easily bored".

4. Cost/Time. Your "custom solutions" will have cost or time constraints which force developers to "just get it done", rather than devise an elegant solution. The same is true of projects, but because they're much larger its a less obvious problem (It's also a project risk, but that's for a different answer).

5. Money - Support work pays a lot less.

6. It's very company specific

---

(i) A greenfield project is one which completely new. The term comes from the building industry; before you have a building, there is only an empty field. Brownfield is where there may have previously been a building and the old stuff is being reused.

Disclaimer: I'm a contractor and have done a lot of both kinds of work. I'm currently doing maintenance.

Answer 7

Matthew's answer has already covered most of the issues with maintenance work although I would call some things a bit short-sighted by future employers. A good Java 7 developer can easily learn the newer standards. There is however one aspect that would keep me from a pure maintenance job: It can be incredibly frustrating and you feel like you get nothing done

We are only a small team and therefore everybody does both maintenance and new development. However, every software has the parts that have been "just working" for eternity written by people that left years ago. Some of these parts predate a lot of our improvements in quality. There is no proper documentation (or none that you can find). There is no test coverage. The code in these parts can be messy and "optimized" in weird ways that cause loads of invisible boundaries to be hit when you try to change something.

Whenever one of those parts stops to "just work", I feel like an archeologist analyzing every probably unimportant detail that could be relevant. Narrowing down a problem can be hard in this systems as they are hard to isolate from their dependencies. In the end you might have spent 2 days and for a fix that consists of one line of code.

And the worst thing is that you cannot fix this for real because once a project or product version is in maintenance mode, you will not get the resources for a major rewrite. If it is feasible to change the big picture at all

Moreover, even maintaining you own code can be a real pain. Once it is out in the wild it gets a lot harder to debug. Instead of attaching a debugger you read logs and hope you chose the right level of instrumentation. Many problems in the wild are depending on user action or, even worse, they are data-dependent. Reproducing such issues requires a lot of cooperation with customers which is not really much fun.

Answer 8

Adding to @Matthew Gaiser

Making a maintainable product is hard. Making a product that requires little maintenance is even harder.

Given choice, developers do neither (and most of them are incapable anyway). They are paid, promoted and praised for adding features and they keep adding features and keep getting good at adding features. Corner cases, error handling or better, thinking-intensive design choices are left behind.

And they either pretty well know what they did (if they are honest to themselves) or face the truth in a rather unpleasant manner when the project gets deployed.

Welcome to the maintenance hell.

---edit:

Maintenance is pretty much similar to development. You make things work. Except...

1. Pressure from the people using the product and needing it working now. The way they are trained to or used to.

2. Responsibility. It is you that will get fired for a royal data loss, not the "rock star" developer that never sees the user data.

3. Constraint of the bad design choices of those "rock stars" that wrote it (it is even worse if those rock stars are you).

4. Complex success metrics: ...well, it's complicated. You take a lot of blame. See other answers.

5. Generally less competent and less motivated people doing maintenance (or having to work with those people if you stay in maintenance).

Answer 9

The other answers have talked about how much fun it is to work on a greenfield project, but there are also good and bad ways to manage maintenance projects. The good way provides plenty of opportunities for developer-initiated improvements, and I think most developers find that almost as rewarding. The bad way is a constant slog spending inordinate amounts of time on what should be simple fixes, then being shot down every time you suggest improvements that could speed you up, like refactors or test and deployment automation.

Answer 10

I'm going to echo GrandmasterB's sentiment in saying that if your developers are only staying 4-9 months then the problem isn't the fact that these developers are being put on maintenance. You have a bigger problem, and the people who are leaving your company and telling you it's because of maintenance are just trying to sugar coat the real issue. While I can't speak for others, one reason why I might do something like this would be because I feel like if I raised the real issue then I wouldn't be listened to. Something, perhaps, like a toxic manager who's been at the company for years and management loves him but all his direct reports complain about him, but HR never does anything because they think he's great and he produces results. Do you know anyone who might fit that description within your organization? (hint: if not, it might be you) . You may want to search your company on Glassdoor and see what people are saying about your company; people tend to be more honest when they are anonymous, and you might find the real reason there. It's important, when looking through Glassdoor reviews to understand most people aren't trying to slander you, they are giving their real advice based on their real experiences, and many companies get defensive when told they have a problem, while you should be introspective and try to solve the problem.

Here's another question which might be illuminating to how your business can be run on a macro-level: Let's say I join your company. You put me on a project for the first 6 months, then I finish the project and you put me on maintenance for the rest of my tenure at the company. Then you want to start a new project, so you hire someone else. Then they go on maintenance. Then you start a new project and hire someone else, and so on. Meanwhile, me and the other guy are still at the company, we are capable developers who could do the project, and you're not utilizing us to fulfill your project needs. Aside from the fact that this makes us feel useless because we're not getting the "interesting" project work, it also means your code base is a mess, because every time you do a new project you hire new people who come into the company with their own standards and experiences and styles. This increases the maintenance cost of your service as a whole because in addition to regular maintenance stuff like data quality and bug triage, we (the maintenance people) have to also understand potentially tens or hundreds of different coding styles from all different people, some of whom may have left the company after submitting their code.

Realistically, you should not have a "project team" and a "maintenance team". You should divide your team by responsibilities or domains, and then every developer in each team is responsible both for new development and also maintenance of whatever is in their domain. Then you have team leaders or engineering managers who divide up those tasks among their team members so everyone gets a decent share of both new development and also maintenance tasks.

Another red flag to me about your company is that you feel the need at all to have a "maintenance team", i.e. a set of developers who are on full-time maintenance duty. This speaks volumes about the quality of your application code. Bugs happen, for sure, but if you have so many bugs that you have a team whose core responsibility is flying from one bug to the next to put out fires, it might be worth considering a rewrite of your application, because this is not supposed to happen. This comes from hiring bad developers, and bad developers are also people who might leave within 4-9 months, like "here's my crappy code, now it's your problem, see ya" (not that good developers don't have reasons to leave quickly, but bad developers have more reasons to leave quickly). You should probably also take a look at your compensation package for your employees and compare it to market rates to see if maybe you are not attracting talent. Talent attracts more talent; I would love to work with people who are smarter than me, but if everyone else is less skilled than me then I have no real reason to stay because I'm not learning or doing anything interesting, and I'm constantly having to fix other people's bad code because nobody writes code as good as my own.

In short:

1) You probably have a problem within your organization in the form of someone toxic in management. Find out who it is and get rid of them.

2) You probably should divide your teams into project domains rather than maintenance vs. project, and have team leads who divvy up project and maintenance tasks to keep your developers happy.

3) You probably should raise your compensation rates to attract talent who can build better code so you have to do less maintenance. You may also want to scrap your current application and rebuild it completely once you have good talent on board to reduce maintenance cost.

Answer 11

This is opinion based, but creating a mess is more fun than cleaning one up.

Maintenance

Generally you're fixing things that weren't done correctly in the first place. Often this is no fault of your own. It could be a genuine mistake, an oversight, other devs being lazy or inexperienced, scope creep, outdated tech etc...

You take the blame for things not working, even if it wasn't your fault. It's stressful and demeaning.

(some devs love finding and fixing problems, other devs hate it)

Developing

You're the creator. You get all the praise for things going right. When issues are discovered later it's maintenance's problem.

Possible Solutions

Maybe the issue you have is more about culture and processes. Make sure developers are building things to a high standard, with clearly defined specifications and processes.

Before a project is due to end, have a meeting to schedule them on another project, giving them something to look forward to, splitting their time between maintenance and a new project.

Developers want to develop (create) don't stick anyone in a purely maintenance (scapegoat) group.

Answer 12

I like Matt's answer but I want to add an example if it isn't already shared. Suppose someone built a house, and that same person now walks around maintaining the house. It would be quite boring to do so mainly because you'll find the common items that break, and chances are everything else is mostly a misunderstanding about how something works. You'll spend more time doing nothing than doing something. Sure there are new projects that may pop up here and there and perhaps at some point extensions to the house may occur but overall your time is spent doing the common maintenance and breakings.

Answer 13

I think most developers want something more challenging than doing simple maintenance, especially if the tech is old, without barely nothing new to learn, no new language/framework/etc. So you're stuck with something that will lead to nothing, that you can't use later in your career if you switch jobs. Also I consider it boring, without much work to do, uninspiring

Answer 14

I am a developer and I also don't like maintenance, indeed it can be compared to janitorial work. The best thing about my job is to be creative and to build things from scratch. But when you do maintenance:

1. You lose a lot of time understanding someone else's code, which is often messy
2. You don't use your creativity, but you just modify something that already exists, and you have to conform to an already existent structure
3. Most importantly: the already existent code can act an an opaque layer between the technology that you are trying to learn and you. The code owned by the company is often worthless outside the company, while general technologies and frameworks (e.g. learning Django) can be very useful and appreciated outside the company, and also very interesting
4. As the codebase grows, the complexity rises and making small changes becomes very complex, which can be demotivating

Reason 2 and 3 can be motivation killers for me. The last thing that I want to hear as a junior developer is that somebody with more experience than me created something that I should use because I am not enough skilled to create something. The latter reason can be true or false, but what I want to do is learning. Relying on someone else's code is like if instead of learning how to drive a car, somebody creates an interface for you, which in the end (1) prevents you from learning how to drive the car, which is what is interesting and valuable, and (2) prevents you from being in control of the car. For how hard it can be, the last thing you want to hear is that you are not being taught to do it yourself.

I am afraid that as a junior I don't have enough experience to give you a concrete list of action points that have been proven to work. But all I can say is that a developer (if he is passionate) sees a company like a learning opportunity, not only as a source of money. What you can do to encourage a developer who works on maintenance is to allow him to be creative, for example by allowing him to rewrite parts of the app by using new technologies and putting his creativity on it.