I'm doing 90% maintenance and 10% development, is this normal?
programmers.stackexchange.com
programmers.stackexchange.com
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.
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.
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.
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.
As I've gained more experience I've realized that maintaining a code base is like any relationship with conflict -- you have to pick your battles carefully or everything turns into a fight / falls apart.
At some point in the growth of a human being, we are discouraged from continually asking "Why?" and from questioning things we see. This is largely a bad idea, so showing junior devs that they are in a position to ask questions and help lead everyone to a better solution is great!
Based on my experience, it would be unrealistic for a junior developer to expect this perspective at a new job. More realistic: here are the things that need to be done for this business to survive; please do them. Maybe some leeway in how you approach the problem. If they wanted unbiased eyes, the job listing would have said consultant, not junior developer.
Believe me, I hear what you're saying. I've tried it many times. For instance: "You don't check everything into source control? Oh my god, it's so basic, look how much better you guys could be doing your jobs!" Which, yeah, it would have been better. It also annoyed the people around me and destabilized the team, even as it improved the technology. Net loss for the company.
Having made this mistake over and over, I want to help others avoid it. Junior developers, know that if you find success in your job, your most important contributions to the company will not have been code. You will not bring some great insight to the table that makes everything faster/better/cheaper and wins you everyone's respect. You earn respect and admiration by working hard (not smart, hard!) and helping the people around you. Look up from your text editor, go talk to people, find out what they're doing, help them succeed.
That's where your focus should be as a junior. (Or as a senior, for that matter.) Helping others succeed. Questioning the status quo is a distraction and not as useful as you think, even if you're right and everyone else is wrong. Maybe especially if you're right.
Not entirely, anyway. You can't turn the whole app into a good one in any reasonable time, but when you fix a bug, take time to apply the boy scout rule ( http://www.informit.com/articles/article.aspx?p=1235624&... ) Don't put that down as a separate task that your management can approve or deny, it's part of doing the job of coding properly. That way, at least the buggy parts of the app get better.
You should not be focused only on your career when making coding and tech decisions, but look at it this way: in a year's time, you're in an interview for a job you really want. What are you going to say "I can read and maintain shitty code" or "I can make shitty code better"?
Also consider: documenting your app's architecture (or lack of it) and conventions (or lack of them).
Also consider: reading up on architecture, testing, refactoring and code quality. If nothing else, these will help you get your next, better job. Off the top of my head, try "Domain Driven Design" by Eric Evans, "Growing object-oriented software guided by tests", "Refactoring" By Martin Fowler, and on the last topic "Clean code" by Robert Martin and "Code Complete" by Steve McConnell
Big ball of mud apps (http://www.laputan.org/mud/ ) may be common, but it doesn't have to be that way - you can learn some pitfalls to avoid
Reductio ad absurdum: If somebody offers me a full time job of sewer-cleaning, paying me 15k, i'd probably pass, because I value other things besides money. I want to enjoy what I do, and the market right now (at least for the dev community) gives me enough options to choose where I want to work.
He'd probably learn A LOT more, somewhere else, working with other people, and where the company actually values him.
Someone would think that the kind of people who hires devs in such conditions, having a high employee turnover, would start to value them a little more. Sadly, my experience knowing a few cases firsthand, is that they think "there's always someone else".
Most likely. I'm suggesting that until that happens, in preparation for that, he can learn as much as he can from what's in front of him; and do a good job too.
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.
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.
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.
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.
If this guy is working on 15 different apps, with no guidance about scheduling or priorities he is in an untenable position.
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 :) .
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.
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.
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
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.
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.
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 :(
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.
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.
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.
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...
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.
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.
If by maintenance you mean "dealing with bugs", then yes, 90% is too much.
But if it includes adding features, then 90% is perfectly normal if not a bit low.
"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.
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.
This is simply not true. You are the one living in the reality distortion field, not Apple.