8 ms·

I'm doing 90% maintenance and 10% development, is this normal?

121 points by pooriaazimi 14y ago

ilaksh 14y ago
The guy is talking about quitting at the end and starting his own thing. My advice is: 1) first find another job that pays more and is generally less ridiculous, with the realization that its hard to find jobs that don't involve a lot of maintenance 2) give your notice 3) while working at your new job, bootstrap your own startup
bwei 14y ago
You could gain experience from that.
- vonmoltke 14y ago
  True, as long as the application design and technology is still relevant. I personally think anyone writing an application of significant size should have some experience maintaining such an application. Gives a sense of why and how to write code for maintainability.
droithomme 14y ago
I enjoy some maintenance, though I don't want to only do only that. It's quite different from the amazingly rapid pace of fresh empty-text-file blue-sky development. In the referenced article though, the person was told he was not allowed to do any proactive refactoring and was only permitted reactionary last minute emergency fixes to bug reports (to paraphrase and expand on what he said, but I am fairly sure this is accurate). That... is a very unpleasant and counterproductive set of restrictions. Without those restrictions, maintenance can be used to gradually convert a giant mud ball mess of hectic changes and poor architectural choices into a robust foundation for future development and a well documented code base that is a joy to work with. With those restrictions, you're constantly putting out fires with a blanket and a bucket of water, but not allowed to buy a firetruck, pass construction safety codes, or establish a network of fire hydrants. Back to the person in the referenced post, given that he is currently the sole maintainer of 4 different mudball applications, has written 4 applications there from scratch, and has 2 new apps under development and 5 more scheduled immediately after, and will be responsible for maintaining all 15 apps, he is clearly very talented and will soon completely burn out. But for him all these details are completely irrelevant anyway. The only important part of his post is this: "My salary is almost equal if not lower then that of a cashier at a supermarket." This is the most important thing he has said and makes the next step he should take clear, and all these details about maintenance unnecessary details.
- gbog 14y ago
  I agreed with you until "[Salary] is the most important thing he has said". For many people salary is not the most important thing in life. If this guy learns a lot doing what he does, salary considerations could be secondary for him. And I think there is a possibility that he is in a position to learn the hard way (in a way he will not forget what he learnt) some of the nasty parts of software development: code base is awful, touching one thing breaks unrelated parts, doing a simple change takes days because of duplication, PM do not care a shit if code is clean or not and don't want to hear about refactor. All of that is crude reality. Only after having endured such evils can someone really understand why duplication is bad, why hidden dependencies is evil, and, even more importantly: How and when to tell or, more often, to NOT tell a PM that you WILL refactor the code before doing this fix, for everyone's sake.
michaelochurch 14y ago
No, not even at entry-level. 90% maintenance is a disaster. 60 to 75 percent might be typical for entry-level programmers, and that's bad, but 90 is abysmal. If development is done properly, "maintenance" isn't some massive chore. It's pay-as-you-go and takes the form of proper testing, early design review and refactoring, and a shared sense of responsibility for the upkeep of the code (none of this "give maintenance work to the juniors" attitude). When a company decides to put its junior people on full-time maintenance to have them pay their dues, it's setting itself up for failure. Unskilled maintenance makes the code worse. Unmotivated maintenance makes the code worse. Finally, even in the best-case scenario where the junior programmer is motivated and skilled, he still doesn't have the clout to do maintenance properly, which often pisses off people who depend on ill-thought-out features. Ideally, people who care about an asset (i.e. who use it) should be the ones to maintain it. Ideally as well, the maintenance overhead should be small enough that the "stakeholder" can perform this maintenance pay-as-you-go at the same time as doing other things. Maintenance is really only done well (and if it's done well, it improves rather than "maintaining" the code) when done by people who have reasons to care about the system they're maintaining. Once a project's maintenance overhead is measured in X full-time developers where X >= 0.5, it's time to stop pissing away time and money and motivation and kill -9 that sucker. The warning range is 0.25 to 0.5 full-time developers. If the maintenance burden is in this range, it's time to get a competent person into fixit mode (not "maintenance", but active improvement and refactoring) immediately. Here's my somewhat long post on the topic: http://michaelochurch.wordpress.com/2011/09/23/taxation-without-representation-why-code-maintenance-fails-and-how-to-fix-it/ http://michaelochurch.wordpress.com/2011/09/23/taxation-with...
- bobbles 14y ago
  My first real programming job was 100% maintenance. It was horrible. Luckily I was able to get out after 6 months, but still wonder about the other guys I was working with there.. hopefully they got out.
  - gcb 14y ago
    He should be glad it's not 90% maintenance and 10% meetings
rprasad 14y ago
Possibly. It depends on the size of the codebase and how many other people are handling maintenance alongside him. In a small codebase, 90% is way too much. In a larger (enterprise-scale) codebase, 90% could be normal if there are employees dedicated to maintenance issues.
jorgeleo 14y ago
Define maintenance... Of your own code? bugs or enhancements?
jp 14y ago
Quick, somebody put this YC link on Reddit so we are allowed to be snarky ! This is too meta for me.
- MrKurtHaeusler 14y ago
  I saw it on Reddit a few days ago.
bluesnowmonkey 14y ago
> (badly coded, developed by multiple programmers over the years, handles the same tasks in different ways, zero structure) Yeah, that's totally normal for a mature application. Better get used to it. > At this moment I'm slightly beginning to get crazy from the daily mails of users (read managers) for each application I have to maintain. Maybe not normal, but common. It's really up to you to manage your business relationships and teach people how to work with you. How well you learn to do so will largely determine your happiness with your career. > The sad thing is I have yet to receive a bug report on anything that I have coded myself... Don't get cocky now. It'll happen. > P.S. My salary is almost equal if not lower then that of a cashier at a supermarket. That's not normal. Even a first job should pay better. In summary: demand more money now, give up on the code quality crusade, and concentrate on learning to work with people.
- jms_ 14y ago
  That's a terrible attitude to encourage. Accepting the status-quo as a junior is a great way to encourage them to never improve or question the more debatable practices. Teaching juniors to care about software quality and software maintainability is hugely important in order to encourage an overall improvement within the software dev industry.
  - quanticle 14y ago
    But at what cost? Yes, overall improvement in the software development industry is great, but it's certainly not worth adding to burdens of this particular overworked software engineer. He or she has enough trouble dealing with the situation as it is, without inviting additional conflict with management.
    - jms_ 14y ago
      The point I was trying to highlight is that time spent on wading through the current situation is time not spent thinking critically about the inherent problems of said situation. I'm not saying to down tools and get on the war path with management, but to rather try to balance accepting whatever you are told and never coming up for air, versus sitting back for a time to analyse the situation and identify potential improvements. Ultimately it comes down to the individual, and whether they want to be a cog in the wheel, or whether they are interested in both improving themselves and thereby improving their employer.
cyanbane 14y ago
I think it depends on a person's definition of "maintenance". I work in an industry where data exchange standards are updated frequently when causes updates to old code. It isn't sexy, but it also isn't bug fixes either. Some people may call it maintenance, some might not.
suyash 14y ago
Mostly at big organizations when programmers join teams, their job is mostly to fix bugs and maintain existing code. Rarely they get to write code from scratch. Correct me if I'm wrong those who are working at big companies.
- GFischer 14y ago
  I'll add a couple of data points to your observation :) . On the two large companies I've worked for, my and most of my team's job was to maintain (and sometimes expand) existing code. Visual Basic 6 was the best I could hope for (I've maintained lots of crap, from Clipper up to Forte TOOL currently, and made a lot of reports in Crystal and SSRS). All the cool projects were either outsourced, bought from a smaller outside company, or fiercely fought for in a battle of politics :) .
dkarl 14y ago
I won't address his pay, but as for his work, this guy is getting bogged down responding to emails about projects that are in maintenance mode, with no new development approved. There are three possibilities. One is that he failed to mention that he has been tasked with user support. The second is that the old projects are buggy or fragile as hell, and maintenance is a big and valuable job that deserves the time he puts into it. The third possibility is that he is being barraged with support requests and enhancement requests which are NOT his job to handle. In that case, this guy's manager needs to run interference and get the other managers out of his face. When you want new features added to projects in maintenance mode, you aren't allowed to harass a developer who has been ordered to only fix bugs on those projects. (It's normal to do so, but that's because people are dicks.) When you need support, you don't harass a developer who isn't tasked with support. (Again, it's completely normal, but only because people are dicks.) The people taking up his time are taking advantage of his experience to get work done that they can't get done the right way. His manager needs to tell all those folks to back the #@%^ off unless they have a valid bug report. Then he can concentrate on his real job: his new development projects and bug fixes on the maintenance projects.
wissler 14y ago
It's not the 90% maintenance that's the problem, it's this: "But then I got to hear I wasn't allowed to improve the existing code and to only focus on bug fixes when a bug gets reported." A product that is not worth improving? This is called a hopeless product, a hopeless company, and a hopeless job prospect.
- gcp 14y ago
  Typical for software with actual users that rely on it. Hell, typical for hardware too like the electronics in your car.
  - wissler 14y ago
    Really. What about Apple hardware and software?
    - gcp 14y ago
      Nobody relies on Apple software or hardware to power their business. (I'm thinking POS applications, machine control etc, see the car electronics example). The closest I can think of is a graphics outfit. You know, the same people that went berserk when Adobe announced the only way to get bugfixes was to upgrade. I wonder why. Outside the reality distortion field people do not rely on Apple.
      - wissler 14y ago
        "Nobody relies on Apple software or hardware to power their business." This is simply not true. You are the one living in the reality distortion field, not Apple.
Hominem 14y ago
I had a developer quit after a week for something similar. One application to do bug fixes and extend. He was allowed to do refactoring but it had to stay mostly in "experimental" branches so we could limit the risk of merging changes into production code. The guy just wanted to re-write everything he saw and refused to consider why we might not want massive changes to a codebase he saw as terrible. We were willing to let him refactor all he wanted as long as we tested and released the code in a controlled manner. If this guy is working on 15 different apps, with no guidance about scheduling or priorities he is in an untenable position.
MrKurtHaeusler 14y ago
After the first sprint, I mean, after you have validated your first MMF, it is all maintenance anyway.
kirillzubovsky 14y ago
This is normal, but it doesn't mean you should take it. Large companies will take advantage of you for as long as you let them. At the end of the day, you will get little in return. If you want to do something meaningful, consider doing a startup. Don't have to do your own, join someone first if you must, but pick a problem that you're interested in solving or team that you like to work with. Your life is too short, use it.
codereview1 14y ago
Are you engaging in developer testing, like unit testing and integration testing? This can help minimize the maintenance so that any change you make doesn't break the code.
bullcrab 14y ago
if you're a moron, yes. LOL!
captobvious 14y ago
Yes, it's normal to do 90% maintenance. But there are two issues here, one is regarding the tasks having to do more with updating/enhancing an existing product, as opposed to creating something new from scratch. This is normal, and not inherently bad in any way. The other issue is the one of mismanagement, which is obvious in this case, and very common. The amount of technical debt indicates that previous developers have either been incompetent, the code reviews/quality control lacking, or they have been under serious pressure forced to cut corners. Managers thinking that "dump every issue regarding this product directly on this developer guy with an urgent e-mail" is actually management. While in fact they push the responsibilities of prioritizing/delegating/allocating resources, onto the developer. This is really bad management. To me these are basically signs of a company competing in the market segment of quick and dirty, good enough, pretty low quality software/services. Think about it, there are huge demands for lower end products and services. But it's not very fulfilling to work for such a company.
brettvallis 14y ago
I developed on enterprise PM application on the SharePoint platform (V2, WSS3.0). Over the past year, I have done 3.8% support, and the rest development. I'm quite happy with that. I've recently been aquired by a larger company who develops a similar product, same windows stack but without the SharePoint flavour. They do an inordinate amount of support. But they do it to themselves - they give their clients the means to beat them up about support: multiple support channels, nd aaggressive SLA's. They have a team of 12 developers and they're always under pressure to maintain their support processes. Sounds like you need some strategic architecting input: which products are important; what functionality can (needs to) be reeingineered; what's profitable and what isn't; what is a realistic support process, timeframe, etc? Then once you've been through all this, you realise how important it is to design simple, reliable products.
savoy11 14y ago
Totally normal, except for the cashier salary bit. Your perceived impact on sales is not related to that, 90% is actually too low, often it could be more. Code quality is often good, but usually is much less important in what we developers tend to think. That's why VB6 product market still exists. Think of it this way - 100% of ANY business is maintenance. Once you build McDonalds and In-and-Out, the rest is 100% maintenance and just actually producing the burgers (what you call maintenance)
xxiao 14y ago
The world is based on statistics, in that sense everything is normal, and special, in the meantime.
Produce 14y ago
Sounds like he's working at a software agency considering the number of "products". Let me say this loud and clear: DO NOT WORK AT A SOFTWARE AGENCY People who start these kinds of businesses are not entrepreneurs. They are naive idiots who think that having 100 bosses instead of 1 means that they are independent and actually own a business. In reality, they are splitting their time between many projects and doing them all very, very badly. Anyone worth their salt will leave a position like that and either get hired by a company who have their own software product or start a business (read: not agency) of their own. If we all boycott this type of business then they will have nobody working for them and will slowly die off.
Sakes 14y ago
Start looking for a new job immediately. As a developer you need 2 things from a job. An opportunity to increase your salary, and opportunities to increase your skills as a developer. I started out at a web shop, I spent roughly 4 years there, and the learning stopped after the first year. Web shops are not about creating great solutions, they are about creating good enough custom solutions because web shops by nature are service based companies. Find yourself a nice little SaaS company where you respect the developers and are given opportunities to create clean maintainable code, and explore different technologies. Otherwise you will just be spending the next few years of your career playing find the broken inline sql query and the only thing you will learn is defensive programming.
SonicSoul 14y ago
while quitting is the easiest choice, there are other ways to deal with this situation and actually making your mark. This could really be an opportunity to do something great. After all, if you go to a place where the code is already great and while work will be much easier and more fun, there may be less opportunities at making your mark. the maintenance probably involves fixing bugs, and dealing with limitation of of the system. Instead of fixing those in a tactical way, one could carefully think the problem through, and provide a more meaningful solution (via complete refactoring at times) that actually makes the system n% better. Of course there is no luxury of being able to spend days on such a problem, so initially nights and weekends may be necessary to break through. Providing meaningful solutions on your own time will achieve at least 2 things. Your peers and management will take notice and start listening when you speak about the system instead of just giving you a task to patch bug #9821, and you will gain more intimate knowledge of the system than anyone around you (since you refactored it). This may take a few years, but through such hard work, you will gain ownership and control and reputation for being the person who made a difference.
chris_wot 14y ago
There are two issues here: 1. He's been given too much work for one person, and they all seem to be have the same priority. I'd be discussing this one with management, try to stay for at the most 12 months to get experience, and if nothing changes make a leap to another job. 2. He can't refactor the code base. Not even if he adds unit tests. It's actually point 2 that concerns me the most. The best that he can do is just do some unit tests for every function of the code that he changes to ensure that it doesn't break any other aspect of the code. Apart from this, not much can be done. Unless he can move on to another role, or perhaps document the code structure or something, then all he can do is jump ship once a suitable amount of time has been had. Sucks, but it happens :(
j45 14y ago
This is a tricky question and you have to be very careful in how you read answers here. First, not enough developers have a 5 or 10 year relationship with one code base. Second, you will find many people here who think it's normal to throw away everything and recode everything, every few years. This is because they work on startups, temporary codebases. A business is an established business model, warts and all. It has found a way to make money, and along the way the codebase to do it will probably look less than ideal. The world of an established business is one of refactoring code. when 10 year old code makes money, it's valuable in any form, unfortunately. Mix this with management who don't understand software being in the custom software development field for themselves and it's a recipe for interesting times. Third, remember you're there to make it better. You won't be able to explain things to anyone in any particular detail. You'll have to learn to manage your managers to get enough breathing room and time to start improving things, if you see fit. As for the pay, it sucks. If this is your first programming gig, remember you can pick the city or the position, never both. If you can commit to learning to solve unreasonable problems for a year in a very controlled experiment, you will grow 3 to 5 years professionally. Programming isn't for everyone, especially being the guy who can sort out messes really well.. It's a skill that pays handsomely with a track record in place.
leothekim 14y ago
I wonder what kind of company this is, e.g. media, marketing, finance, tech, etc. If you're not in a tech company - or sometimes even if you are - you're usually considered a cost center instead of a value provider. This would explain why the company is paying badly, why there's more maintenance than new development opportunities, and the overall managerial direction of trying to squeeze every ounce of productivity out of the poor poster. I'm sure the poster could eke out a salary bump if she were to complain about her workload and state her responsibilities and accomplishments. Doubtful that her responsibilities would change though, and more likely management would ask for more in return.

121 points by pooriaazimi 14y ago

The guy is talking about quitting at the end and starting his own thing. My advice is: 1) first find another job that pays more and is generally less ridiculous, with the realization that its hard to find jobs that don't involve a lot of maintenance 2) give your notice 3) while working at your new job, bootstrap your own startup

bwei 14y ago

You could gain experience from that.

vonmoltke 14y ago
True, as long as the application design and technology is still relevant. I personally think anyone writing an application of significant size should have some experience maintaining such an application. Gives a sense of why and how to write code for maintainability.

droithomme 14y ago

I enjoy some maintenance, though I don't want to only do only that. It's quite different from the amazingly rapid pace of fresh empty-text-file blue-sky development. In the referenced article though, the person was told he was not allowed to do any proactive refactoring and was only permitted reactionary last minute emergency fixes to bug reports (to paraphrase and expand on what he said, but I am fairly sure this is accurate). That... is a very unpleasant and counterproductive set of restrictions. Without those restrictions, maintenance can be used to gradually convert a giant mud ball mess of hectic changes and poor architectural choices into a robust foundation for future development and a well documented code base that is a joy to work with. With those restrictions, you're constantly putting out fires with a blanket and a bucket of water, but not allowed to buy a firetruck, pass construction safety codes, or establish a network of fire hydrants. Back to the person in the referenced post, given that he is currently the sole maintainer of 4 different mudball applications, has written 4 applications there from scratch, and has 2 new apps under development and 5 more scheduled immediately after, and will be responsible for maintaining all 15 apps, he is clearly very talented and will soon completely burn out. But for him all these details are completely irrelevant anyway. The only important part of his post is this: "My salary is almost equal if not lower then that of a cashier at a supermarket." This is the most important thing he has said and makes the next step he should take clear, and all these details about maintenance unnecessary details.

gbog 14y ago
I agreed with you until "[Salary] is the most important thing he has said". For many people salary is not the most important thing in life. If this guy learns a lot doing what he does, salary considerations could be secondary for him. And I think there is a possibility that he is in a position to learn the hard way (in a way he will not forget what he learnt) some of the nasty parts of software development: code base is awful, touching one thing breaks unrelated parts, doing a simple change takes days because of duplication, PM do not care a shit if code is clean or not and don't want to hear about refactor. All of that is crude reality. Only after having endured such evils can someone really understand why duplication is bad, why hidden dependencies is evil, and, even more importantly: How and when to tell or, more often, to NOT tell a PM that you WILL refactor the code before doing this fix, for everyone's sake.

michaelochurch 14y ago

No, not even at entry-level. 90% maintenance is a disaster. 60 to 75 percent might be typical for entry-level programmers, and that's bad, but 90 is abysmal. If development is done properly, "maintenance" isn't some massive chore. It's pay-as-you-go and takes the form of proper testing, early design review and refactoring, and a shared sense of responsibility for the upkeep of the code (none of this "give maintenance work to the juniors" attitude). When a company decides to put its junior people on full-time maintenance to have them pay their dues, it's setting itself up for failure. Unskilled maintenance makes the code worse. Unmotivated maintenance makes the code worse. Finally, even in the best-case scenario where the junior programmer is motivated and skilled, he still doesn't have the clout to do maintenance properly, which often pisses off people who depend on ill-thought-out features. Ideally, people who care about an asset (i.e. who use it) should be the ones to maintain it. Ideally as well, the maintenance overhead should be small enough that the "stakeholder" can perform this maintenance pay-as-you-go at the same time as doing other things. Maintenance is really only done well (and if it's done well, it improves rather than "maintaining" the code) when done by people who have reasons to care about the system they're maintaining. Once a project's maintenance overhead is measured in X full-time developers where X >= 0.5, it's time to stop pissing away time and money and motivation and kill -9 that sucker. The warning range is 0.25 to 0.5 full-time developers. If the maintenance burden is in this range, it's time to get a competent person into fixit mode (not "maintenance", but active improvement and refactoring) immediately. Here's my somewhat long post on the topic: http://michaelochurch.wordpress.com/2011/09/23/taxation-without-representation-why-code-maintenance-fails-and-how-to-fix-it/ http://michaelochurch.wordpress.com/2011/09/23/taxation-with...

bobbles 14y ago
My first real programming job was 100% maintenance. It was horrible. Luckily I was able to get out after 6 months, but still wonder about the other guys I was working with there.. hopefully they got out.
- gcb 14y ago
  He should be glad it's not 90% maintenance and 10% meetings

rprasad 14y ago

Possibly. It depends on the size of the codebase and how many other people are handling maintenance alongside him. In a small codebase, 90% is way too much. In a larger (enterprise-scale) codebase, 90% could be normal if there are employees dedicated to maintenance issues.

jorgeleo 14y ago

Define maintenance... Of your own code? bugs or enhancements?

jp 14y ago

Quick, somebody put this YC link on Reddit so we are allowed to be snarky ! This is too meta for me.

MrKurtHaeusler 14y ago
I saw it on Reddit a few days ago.

bluesnowmonkey 14y ago

> (badly coded, developed by multiple programmers over the years, handles the same tasks in different ways, zero structure) Yeah, that's totally normal for a mature application. Better get used to it. > At this moment I'm slightly beginning to get crazy from the daily mails of users (read managers) for each application I have to maintain. Maybe not normal, but common. It's really up to you to manage your business relationships and teach people how to work with you. How well you learn to do so will largely determine your happiness with your career. > The sad thing is I have yet to receive a bug report on anything that I have coded myself... Don't get cocky now. It'll happen. > P.S. My salary is almost equal if not lower then that of a cashier at a supermarket. That's not normal. Even a first job should pay better. In summary: demand more money now, give up on the code quality crusade, and concentrate on learning to work with people.

jms_ 14y ago
That's a terrible attitude to encourage. Accepting the status-quo as a junior is a great way to encourage them to never improve or question the more debatable practices. Teaching juniors to care about software quality and software maintainability is hugely important in order to encourage an overall improvement within the software dev industry.
- quanticle 14y ago
  But at what cost? Yes, overall improvement in the software development industry is great, but it's certainly not worth adding to burdens of this particular overworked software engineer. He or she has enough trouble dealing with the situation as it is, without inviting additional conflict with management.
  - jms_ 14y ago
    The point I was trying to highlight is that time spent on wading through the current situation is time not spent thinking critically about the inherent problems of said situation. I'm not saying to down tools and get on the war path with management, but to rather try to balance accepting whatever you are told and never coming up for air, versus sitting back for a time to analyse the situation and identify potential improvements. Ultimately it comes down to the individual, and whether they want to be a cog in the wheel, or whether they are interested in both improving themselves and thereby improving their employer.

cyanbane 14y ago

I think it depends on a person's definition of "maintenance". I work in an industry where data exchange standards are updated frequently when causes updates to old code. It isn't sexy, but it also isn't bug fixes either. Some people may call it maintenance, some might not.

suyash 14y ago

Mostly at big organizations when programmers join teams, their job is mostly to fix bugs and maintain existing code. Rarely they get to write code from scratch. Correct me if I'm wrong those who are working at big companies.

GFischer 14y ago
I'll add a couple of data points to your observation :) . On the two large companies I've worked for, my and most of my team's job was to maintain (and sometimes expand) existing code. Visual Basic 6 was the best I could hope for (I've maintained lots of crap, from Clipper up to Forte TOOL currently, and made a lot of reports in Crystal and SSRS). All the cool projects were either outsourced, bought from a smaller outside company, or fiercely fought for in a battle of politics :) .

dkarl 14y ago

I won't address his pay, but as for his work, this guy is getting bogged down responding to emails about projects that are in maintenance mode, with no new development approved. There are three possibilities. One is that he failed to mention that he has been tasked with user support. The second is that the old projects are buggy or fragile as hell, and maintenance is a big and valuable job that deserves the time he puts into it. The third possibility is that he is being barraged with support requests and enhancement requests which are NOT his job to handle. In that case, this guy's manager needs to run interference and get the other managers out of his face. When you want new features added to projects in maintenance mode, you aren't allowed to harass a developer who has been ordered to only fix bugs on those projects. (It's normal to do so, but that's because people are dicks.) When you need support, you don't harass a developer who isn't tasked with support. (Again, it's completely normal, but only because people are dicks.) The people taking up his time are taking advantage of his experience to get work done that they can't get done the right way. His manager needs to tell all those folks to back the #@%^ off unless they have a valid bug report. Then he can concentrate on his real job: his new development projects and bug fixes on the maintenance projects.

wissler 14y ago

It's not the 90% maintenance that's the problem, it's this: "But then I got to hear I wasn't allowed to improve the existing code and to only focus on bug fixes when a bug gets reported." A product that is not worth improving? This is called a hopeless product, a hopeless company, and a hopeless job prospect.

gcp 14y ago
Typical for software with actual users that rely on it. Hell, typical for hardware too like the electronics in your car.
- wissler 14y ago
  Really. What about Apple hardware and software?
  - gcp 14y ago
    Nobody relies on Apple software or hardware to power their business. (I'm thinking POS applications, machine control etc, see the car electronics example). The closest I can think of is a graphics outfit. You know, the same people that went berserk when Adobe announced the only way to get bugfixes was to upgrade. I wonder why. Outside the reality distortion field people do not rely on Apple.
    - wissler 14y ago
      "Nobody relies on Apple software or hardware to power their business." This is simply not true. You are the one living in the reality distortion field, not Apple.

Hominem 14y ago

I had a developer quit after a week for something similar. One application to do bug fixes and extend. He was allowed to do refactoring but it had to stay mostly in "experimental" branches so we could limit the risk of merging changes into production code. The guy just wanted to re-write everything he saw and refused to consider why we might not want massive changes to a codebase he saw as terrible. We were willing to let him refactor all he wanted as long as we tested and released the code in a controlled manner. If this guy is working on 15 different apps, with no guidance about scheduling or priorities he is in an untenable position.

MrKurtHaeusler 14y ago

After the first sprint, I mean, after you have validated your first MMF, it is all maintenance anyway.

kirillzubovsky 14y ago

This is normal, but it doesn't mean you should take it. Large companies will take advantage of you for as long as you let them. At the end of the day, you will get little in return. If you want to do something meaningful, consider doing a startup. Don't have to do your own, join someone first if you must, but pick a problem that you're interested in solving or team that you like to work with. Your life is too short, use it.

codereview1 14y ago

Are you engaging in developer testing, like unit testing and integration testing? This can help minimize the maintenance so that any change you make doesn't break the code.

bullcrab 14y ago

if you're a moron, yes. LOL!

captobvious 14y ago

Yes, it's normal to do 90% maintenance. But there are two issues here, one is regarding the tasks having to do more with updating/enhancing an existing product, as opposed to creating something new from scratch. This is normal, and not inherently bad in any way. The other issue is the one of mismanagement, which is obvious in this case, and very common. The amount of technical debt indicates that previous developers have either been incompetent, the code reviews/quality control lacking, or they have been under serious pressure forced to cut corners. Managers thinking that "dump every issue regarding this product directly on this developer guy with an urgent e-mail" is actually management. While in fact they push the responsibilities of prioritizing/delegating/allocating resources, onto the developer. This is really bad management. To me these are basically signs of a company competing in the market segment of quick and dirty, good enough, pretty low quality software/services. Think about it, there are huge demands for lower end products and services. But it's not very fulfilling to work for such a company.

brettvallis 14y ago

I developed on enterprise PM application on the SharePoint platform (V2, WSS3.0). Over the past year, I have done 3.8% support, and the rest development. I'm quite happy with that. I've recently been aquired by a larger company who develops a similar product, same windows stack but without the SharePoint flavour. They do an inordinate amount of support. But they do it to themselves - they give their clients the means to beat them up about support: multiple support channels, nd aaggressive SLA's. They have a team of 12 developers and they're always under pressure to maintain their support processes. Sounds like you need some strategic architecting input: which products are important; what functionality can (needs to) be reeingineered; what's profitable and what isn't; what is a realistic support process, timeframe, etc? Then once you've been through all this, you realise how important it is to design simple, reliable products.

savoy11 14y ago

Totally normal, except for the cashier salary bit. Your perceived impact on sales is not related to that, 90% is actually too low, often it could be more. Code quality is often good, but usually is much less important in what we developers tend to think. That's why VB6 product market still exists. Think of it this way - 100% of ANY business is maintenance. Once you build McDonalds and In-and-Out, the rest is 100% maintenance and just actually producing the burgers (what you call maintenance)

xxiao 14y ago

The world is based on statistics, in that sense everything is normal, and special, in the meantime.

Produce 14y ago

Sounds like he's working at a software agency considering the number of "products". Let me say this loud and clear: DO NOT WORK AT A SOFTWARE AGENCY People who start these kinds of businesses are not entrepreneurs. They are naive idiots who think that having 100 bosses instead of 1 means that they are independent and actually own a business. In reality, they are splitting their time between many projects and doing them all very, very badly. Anyone worth their salt will leave a position like that and either get hired by a company who have their own software product or start a business (read: not agency) of their own. If we all boycott this type of business then they will have nobody working for them and will slowly die off.

Sakes 14y ago

Start looking for a new job immediately. As a developer you need 2 things from a job. An opportunity to increase your salary, and opportunities to increase your skills as a developer. I started out at a web shop, I spent roughly 4 years there, and the learning stopped after the first year. Web shops are not about creating great solutions, they are about creating good enough custom solutions because web shops by nature are service based companies. Find yourself a nice little SaaS company where you respect the developers and are given opportunities to create clean maintainable code, and explore different technologies. Otherwise you will just be spending the next few years of your career playing find the broken inline sql query and the only thing you will learn is defensive programming.

SonicSoul 14y ago

while quitting is the easiest choice, there are other ways to deal with this situation and actually making your mark. This could really be an opportunity to do something great. After all, if you go to a place where the code is already great and while work will be much easier and more fun, there may be less opportunities at making your mark. the maintenance probably involves fixing bugs, and dealing with limitation of of the system. Instead of fixing those in a tactical way, one could carefully think the problem through, and provide a more meaningful solution (via complete refactoring at times) that actually makes the system n% better. Of course there is no luxury of being able to spend days on such a problem, so initially nights and weekends may be necessary to break through. Providing meaningful solutions on your own time will achieve at least 2 things. Your peers and management will take notice and start listening when you speak about the system instead of just giving you a task to patch bug #9821, and you will gain more intimate knowledge of the system than anyone around you (since you refactored it). This may take a few years, but through such hard work, you will gain ownership and control and reputation for being the person who made a difference.

chris_wot 14y ago

There are two issues here: 1. He's been given too much work for one person, and they all seem to be have the same priority. I'd be discussing this one with management, try to stay for at the most 12 months to get experience, and if nothing changes make a leap to another job. 2. He can't refactor the code base. Not even if he adds unit tests. It's actually point 2 that concerns me the most. The best that he can do is just do some unit tests for every function of the code that he changes to ensure that it doesn't break any other aspect of the code. Apart from this, not much can be done. Unless he can move on to another role, or perhaps document the code structure or something, then all he can do is jump ship once a suitable amount of time has been had. Sucks, but it happens :(

j45 14y ago

This is a tricky question and you have to be very careful in how you read answers here. First, not enough developers have a 5 or 10 year relationship with one code base. Second, you will find many people here who think it's normal to throw away everything and recode everything, every few years. This is because they work on startups, temporary codebases. A business is an established business model, warts and all. It has found a way to make money, and along the way the codebase to do it will probably look less than ideal. The world of an established business is one of refactoring code. when 10 year old code makes money, it's valuable in any form, unfortunately. Mix this with management who don't understand software being in the custom software development field for themselves and it's a recipe for interesting times. Third, remember you're there to make it better. You won't be able to explain things to anyone in any particular detail. You'll have to learn to manage your managers to get enough breathing room and time to start improving things, if you see fit. As for the pay, it sucks. If this is your first programming gig, remember you can pick the city or the position, never both. If you can commit to learning to solve unreasonable problems for a year in a very controlled experiment, you will grow 3 to 5 years professionally. Programming isn't for everyone, especially being the guy who can sort out messes really well.. It's a skill that pays handsomely with a track record in place.

leothekim 14y ago

I wonder what kind of company this is, e.g. media, marketing, finance, tech, etc. If you're not in a tech company - or sometimes even if you are - you're usually considered a cost center instead of a value provider. This would explain why the company is paying badly, why there's more maintenance than new development opportunities, and the overall managerial direction of trying to squeeze every ounce of productivity out of the poor poster. I'm sure the poster could eke out a salary bump if she were to complain about her workload and state her responsibilities and accomplishments. Doubtful that her responsibilities would change though, and more likely management would ask for more in return.