
I'm doing 90% maintenance and 10% development, is this normal? - pooriaazimi
http://programmers.stackexchange.com/q/152464/17163
======
bluesnowmonkey
> (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_
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
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_
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.

~~~
kamaal
>>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.

Yes this is important, but I think if your employer is in mood to listen. The
next immediate step for you must be to start fishing for a job outside. And
there is a reason for that. Your time is worth doing something important which
is rewarding to you and your employer(I mean both in terms of value and
financially).

Challenge the status quo and try to improve things, if you absolutely
cannot(for reasons beyond your control) you must leave people to their state
and move on.

------
droithomme
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
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.

------
dkarl
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.

------
Sakes
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.

------
Hominem
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.

------
suyash
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
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 :) .

------
cyanbane
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.

------
j45
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.

------
ilaksh
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

------
captobvious
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
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.

------
chris_wot
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
:(

------
leothekim
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.

------
SonicSoul
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.

------
kirillzubovsky
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.

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

------
Produce
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.

------
codereview1
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.

------
bwei
You could gain experience from that.

~~~
vonmoltke
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.

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

------
michaelochurch
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-
with...](http://michaelochurch.wordpress.com/2011/09/23/taxation-without-
representation-why-code-maintenance-fails-and-how-to-fix-it/)

~~~
nandemo
> 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.

In my experience and from what I've gathered from friends and coworkers over
the years, ratios like that are actually quite normal.

And it doesn't have to do with entry-level vs. senior. I suppose a lot of
HNers are working at tech startups or otherwise companies that build software-
based products. But there's a lot of custom software out there (I'd say the
large majority of running software as well as the large majority of software
being written is custom, though I have no data to back that up). So lots of
devs are either working in-house for non-software large companies, or working
for companies that build custom software for such companies, and that usually
entails a lot of maintenance work.

~~~
mgse
I'd agree. Those ratios sound pretty reasonable for firmware. Actually, 60%
was probably a good year.

I worked on i&p series servers at IBM and a vast majority of what we did
wasn't really new functionality. It was more adapting the existing code base
to the next gen hardware. Power on sequences had to be modified, hardware
access went from GPIO to I2C and vice-versa, and the rules of what could be
plugged into where under what conditions were always changing.

And once everything was working, you've got years of support to look forward
to. It wasn't uncommon to get pulled into discussions for products released 5+
years ago.

As an aside, hardware enablement might not be flashy work, but it can be loads
of fun even if you're not writing massive amounts of new code. Sure, the
documentation stinks and the first pass of hardware is about as good as
airport TP, but it is amazing feeling when it finally works.

------
rprasad
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.

------
wissler
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
Typical for software with actual users that rely on it. Hell, typical for
hardware too like the electronics in your car.

~~~
wissler
Really. What about Apple hardware and software?

~~~
gcp
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
"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.

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

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

~~~
MrKurtHaeusler
I saw it on Reddit a few days ago.

