> (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.
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.
When I was junior I really thought that everything can be fixed.
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.
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.
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.
>>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.
Yes, but a junior developer's role in any company regardless of size is most definitely not to come in and say how they could do it better and the company should change their workflow.
I totally agree, but the value that a junior developer can bring to the table is a pair of unbiased eyes. It's what I look for when new developers join any existing team I am on: what can they see that we can't.
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!
> It's what I look for when new developers join any existing team I am on: what can they see that we can't.
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.
Also realize that junior devs often lack the experience needed to distinguish good code from bad and when it Is appropriate to rewrite large parts of an existing application that currently meets the needs of its customers
demand more money now, concentrate on learning to work with people, but do not give up on code quality.
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
I don't think that money resolves everything (at least, normal sums of money, lol). If they are paying him the minimum, that means they don't value what he does. I guess that's the reason he has a lot of projects to handle... probably other developers have left for the same reasons.
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".
> He'd probably learn A LOT more, somewhere else, working with other people, and where the company actually values him.
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.
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.
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.
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.
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.
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.
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.
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 :) .
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.
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.
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
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 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.
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 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
I think it has more to do with primarily only having experience with code you wrote yourself or a small codebase written by yourself and others. I have a tongue in cheek saying of "If you haven't maintained code written by others then you probably write code like an asshole". You learn a lot about what never to do by working with very large (and/or very old) codebases that you yourself didn't design. Also, to be fair to the people that did design them, even your greatest most beautiful design will look terrible to some people, and likely to posterity.
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.
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.
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.
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.