Our code is bad. It might not have always been considered bad, but it is bad and is only going downhill. I started fresh out of college less than a year ago, and many of the things in our code puzzle me beyond belief. At first I figured that as the new guy I should keep my mouth shut until I learned a little more about our code base, but I've seen plenty to know that it's bad.

Some of the highlights:

  • We still use frames (try getting something out of a querystring, almost impossible)
  • VBScript
  • Source Safe
  • We 'use' .NET - by that I mean we have .net wrappers that call COM DLLs making it almost impossible to debug easily
  • Everything is basically one giant function
  • Code is not maintainable. Each page has multiple files that are created every time a new page is made. The main page basically does Response.Write() a bunch of times to render the HTML (runat="server"? no way). After that there can be a lot of logic on the client side (VBScript), and finally the page submits to itself (often time storing many things in hidden fields) where it then posts to a processing page which can do things such as save the data to the database.
  • The specifications we get are laughable. Often times they call for things like "auto-populate field X with either field Y or field Z" with no indication of when to choose field Y or field Z.

I'm sure some of this is a result of not being employed at a software company, but I feel as if people writing software should at least care about the quality of their code. I can't even imagine that if I were to bring something up that anything would be done soon, as there is a large deadline looming, but we are continuing to write bad code and use bad practices.

What can I do? How do I even bring these issues up? 75% of my team agree with me and have brought up these issues in the past, yet nothing gets changed.

  • 27
    get used to it. 90% of writing code is reading code.
    – MartyTPS
    Commented Oct 27, 2011 at 0:44
  • 7
    nothing gets changed for the same reason that it is bad code in the first place. They stopped paying booku $$$$ for anyone to give a hoot a long time ago.
    – MartyTPS
    Commented Oct 27, 2011 at 0:46
  • 11
    This is off-topic. But the short answer is: economics. How many developer-months will it cost to tidy the codebase up, and many developer-months will a tidy codebase save? Commented Oct 27, 2011 at 0:47
  • 89
    the best way is in an exit interview.
    – kylben
    Commented Oct 27, 2011 at 1:41
  • 32
    It doesn't matter how you speak to the blind about color. They will not understand you.
    – ThomasX
    Commented Oct 27, 2011 at 8:12

16 Answers 16


Make sure that you're not overreacting. You are fresh, probably haven't worked a lot of (any?) other places, and so aren't prepared for the world of "real life code." Real life code is a horrible thing. It's like your nice school code and your obsessively tweaked personal project code had sex in the basement of a nuclear reactor and the baby grew up in a sewer of toxic waste; it's a hideous mutant.

But assuming you're right, and the code is as bad as you say (i.e. worse than just the typically bad code), then you're right to be concerned. Talk to your team, and determine whether everyone else is on side. It will take work to improve the situation - if the rest of the team recognise the problem but don't care then you're wasting your time.

Being a junior, you probably aren't in a position to lead. If you go to management yourself, as a new hire who is also a junior, your opinion will probably be disregarded. Get your lead developer or one of the most senior guys involved. Again, if none of the senior people are interested then you're wasting your time.

Assuming you can get some senior technical people interested, I'd work towards identifying problem areas and possible solutions. For example, if "everything is basically one giant function" then next time you're working in that 'giant function' maybe you should refactor a little. Again, you need to get everyone onside. If you chip away at little pieces of your problem & improve piece by piece eventually they'll become much less of a problem. Every time you touch a piece of code consider whether it can be improved.

You aren't going to sit down with management and say 'everything is bad and needs to be rewritten'. That makes no sense for them - costs a lot and is potentially very risky. Instead they should be made aware that there are problems, and that there's a plan to slowly improve as changes are made. They should be educated on the benefits of maintainable code. This should come from a senior person that they trust technically and professionally - not from you.

Complete rewrite? Almost always a bad idea.

Ultimately there's not much you can do because you're new. If no one wants to improve things, then you gather your experience and move to the next place.

  • 10
    +1 for the last line alone. People are usually unwilling to listen to a newbie, even if the newbie provides their own experience and a different perspective that everyone else is too inundated into corporate culture to see. People are also blind to hear the truth (i.e. "Everything is bad because the people who set it up were idiots who didn't know WTF they were doing") and would rather go down with the ship than admit things are bad and need to be fixed. It's mind-boggling sometimes how business owners will risk losing everything rather than take the time to fix bad things. Commented Oct 27, 2011 at 14:13
  • 2
    To continue on that last point, I've seen many places where the management would rather run the risk of going out of business when the shoddy system collapses in on itself than to actually man up and address issues, even if those issues means holding off on new features. Commented Oct 27, 2011 at 14:15
  • 5
    Unfortunately, using a kind of 'guerrilla warfare' approach to re-factoring can sometimes lead to you shooting yourself in the foot. Unless the system has a good set of unit/integration tests written against it (which if it is bad it most likely will not) will inevitably lead to the introduction of bugs that will need an entire system test to be passed through QA to avoid. Commented Oct 27, 2011 at 20:18
  • 1
    @aceinthehole: exactly right. If testing is expensive, management will not want to risk any 'unnecessary' changes, even though without them the system will become unmaintainable in the foreseeable future. Commented Oct 28, 2011 at 19:28
  • 2
    @WayneM, and those idiots who didn't know WTF they were doing at the beginning of the project are now the senior managers. Never forget that part!
    – HLGEM
    Commented Oct 28, 2011 at 19:52

Read Joel On Software - things you should never do. Understand his reasoning, then read a few other article on bad software and how to fix it, written by managers, not programmers. Armed with this information you will be able to present a case for fixing it, in terms that managers understand and care about. Hint: Good managers don't spend time and money based solely on programmers opinions and feelings about what must be done.

"This code is crap and needs rewriting" is certainly going to get thrown back at you, even if you are technically correct.

"We can take months off the current project schedule, costing less and make it more reliable." will get their attention (notice lack of mention of the HOW you intend to do this at his stage.

Whatever you say, be certain you are correct. If you say it's bad, your rewrite has to be bloody good.If you say it will take a week, you had better be sure it will be a week, and be good. Any defect in the reworked code will cost you, personally, dearly, regardless of what might have happened had you not done the rework. If someone has been there before you and screwed up or oversold a rewrite, give up, managers don't like being made fools of and won't let it happen twice. By that token, don't screw it up for the guys that follow, you only get one shot at this...

Find ways to spread the cost over a period of time or number of projects. Managers hate risk, speculative investment and negative cash flow - work within your managers tolerances of these. Start with a small, low risk, low cost suggestion. Once you are proved right, you can go for the bigger fish.

  • 2
    funny ... i got voted down for suggesting Joel's site :-) Commented Oct 27, 2011 at 3:36
  • 6
    @Robert French: your manager is reading your posts... Commented Oct 27, 2011 at 12:02
  • 8
    No kidding. It's not fun to try to argue for "Can I have 6 months of developer time to rewrite everything? The end result will be exactly what we have today, but probably with a few new bugs. Oh, and we are going to use many of the same developers who created the current steaming pile of crap for the re-write because they know better now."
    – JohnFx
    Commented Oct 27, 2011 at 14:38
  • 3
    @joshin4colours: <quote>Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. ... Each of these bugs took weeks of real-world usage before they were found. ... When you throw away code and start from scratch, you are throwing away all that knowledge.</quote> Commented Oct 27, 2011 at 15:37
  • 4
    Sorry but one year experience does not grant the credibility to make any of these claims to his management.
    – Jeremy
    Commented Oct 27, 2011 at 16:36

First of all, you'll find goofy legacy stuff anywhere you work as a programmer unless you work at a start-up and you're the one who creates the original goofy legacy code. You have to be able to roll with these punches if you plan on having a career in programming.

Secondly, there are often cost considerations to improving old systems. For example, I've seen more than one company that had 10 year old VB6 and classic ASP applications still in operation. In some cases, this was because a big project to move .NET failed badly. In others, the reason was "if it ain't broke, don't fix it". But, in others, the cost of the move is justifiable since problems caused by the legacy system are to big to ignore.

In situations where there has been a big failure in the past it's almost impossible to bring about a change. In that case, polish up your resume and start looking for a new job. If it's not broken, you probably won't have cause to complain about the code itself but that you weren't on a fulfilling and growing career path. If it is broken, and it sounds like it is in your case, that's when you have a chance at change.

The best approach I've seen is not to bite off too much but to begin with incremental changes that will have the most positive impact. Based on your description, better managing change requests would be a place to start. Once that's under control you can start looking into creating a service framework or other incremental design/code improvements.

The worst approach I've seen is to try to make a great leap directly from a legacy system to the latest and greatest, for example, jumping from a working but clunky VB6/Classic ASP/COM+ system to a MVC/Entity Framework system.

  • 3
    "First of all, you'll find goofy legacy stuff anywhere you work as a programmer unless you work at a start-up and you're the one who creates the original goofy legacy code." I was the first programmer at my startup. Eight latter I often find myself saying 'who wrote this goofy code?', only to check and discover I'm the guilty party. Commented Oct 27, 2011 at 19:36
  • Speed of iteration beats quality of iteration. In other words, make lots of small changes, often, and eventually you will be getting where you want to be.
    – jasonk
    Commented Mar 21, 2012 at 13:59

"Hey Boss, after Big Project me and the team would like some time, ideally X months, to organize our code. Things that should be able to be done in minutes take hours because it is all very disorganized. If it's not possible to do it right after Big Project, we would like to plan a realistic schedule."

(partially paraphrased from Azkar's comment on the question)

  • 10
    In theory, this would be great. In practice, the answer would be something along the lines of "No, the CEO wants Another Big Project done in X months." or "We have y new features that need to be done right away, we don't have time to fix what already works" Commented Oct 27, 2011 at 14:10
  • 2
    That rarely (if ever) works. Especially if you have a manager who's been around for a while, because he/she will have heard this line before only to see it blow up.
    – taylonr
    Commented Oct 27, 2011 at 14:48
  • 1
    This just makes me chuckle. You are never going to get a full re-write into the schedule. What you could potentially do is have smaller task in each upcoming project to improve some sub-system so that eventually (over the course of a couple of years) it is brought to spec. Commented Oct 27, 2011 at 15:50
  • In my experience, this approach will often get rejected. An alternative approach is to multiple Big Project estimates by 1.5 and spend 1/3rd of the time cleaning up the code along the way. Commented Oct 27, 2011 at 18:50
  • 2
    A very frequent response is "Who will fund your paycheck doing this?" If you do not have direct sponsorship of the task, you will need to have the company do the long term investment. Or will you work for free while doing this?
    – user1249
    Commented Oct 28, 2011 at 20:00

Start reading Joel on Software (Joel Spolsky / Founder of Stack Exchange) ...

The FIRST thing I would do is perform a Joel Test.

This will allow you to present it as "While I was looking for ways to improve as a developer... I stumbled onto this 12 question test about development environments, so for fun I answered them about where I work." ... This in turn makes it a 3rd party outlining whats wrong with your code and not you personally.

As you read more on Pragmatic Practices you will be improving yourself and implementing things like red / green / refactor and this in turn will allow you to clean up the code base so that is becomes maintainable. (over time)

Hope that helps! Welcome to Programming (yesterdays code usually sucks) ;-)

  • 4
    I don't think this addresses how he should approach management.
    – Pubby
    Commented Oct 27, 2011 at 1:07
  • 3
    It seems Azbar knows the problem and knows how to fix it, but he doesn't know how to get the ball rolling so that it can be fixed.
    – Pubby
    Commented Oct 27, 2011 at 1:31
  • 1
    Yes ... I was suggesting using a 3rd party's point of view when presenting it. I didn't think he was asking specifically how to talk to his boss. Commented Oct 27, 2011 at 2:02
  • 4
    This answer hardly deserves so many down votes. The first sentence deserves +10. The problem with approaching management is understanding whats important to them, Joel, and this answer, address this kind of problem by looking at the reasons why, and why not, from a business perspective, code should be rewritten.
    – mattnz
    Commented Oct 27, 2011 at 2:42
  • 1
    @Robert French +1 for a good answer. It is important for Azkar to under stand the business as well as the technology. Suggesting he form his own opinion from the observations of a highly qualified 3rd person will help in Azkar's development as a developer, and not just a coder. Besides, the PB&J story is funny.
    – bakoyaro
    Commented Oct 27, 2011 at 4:11

Quick tip: if you do propose management with a list of reasons why you should code differently, include as an argument "Improved morale / working conditions for the programmers".

Make it clear that the tech team will be more content writing and maintaining clean code than this current mess, and this can certainly improve your attitude towards work. Could be a useful argument.

  • definitely a good idea and also very true
    – sdm350
    Commented Oct 28, 2011 at 3:46
  • Does management actually dictate the design? If you have most of the team behind you, what's stopping you? Be proactive and decide as a group. Come up with a plan to implement it incrementally. Then do it.
  • Does management dictate the development tools you use? Unless there is a time cost to swapping out a tool management usually doesn't care. Be proactive and decide as a group what development tools you want to use. If you need buy off from management then show them a migration plan and cost benefit analysis. Then do it.
  • Does management dictate the languages you use? Be proactive and decide as a group what to use instead of VBScript. Come up with a plan to implement it incrementally and and do it. If you need management buy off show them the plan. Then do it.
  • I've got nothing for specs. That's usually highly dependent on the people and processes at your work. Identifying what is broken and the minimal changes required to fix the process takes time, analysis and understanding of how things currently work and how they should work. If you know that you can come up with a plan and try and convince management.

You get more change and respect if propose ways of changing that don't involve large amounts of dedicated time with no (or soft) business value to show for it.

  • No/Yes/Yes. The choice of language and tools are rarely a choice made for technical reasons. (see: parashift.com/c++-faq-lite/big-picture.html#faq-6.5) They are the tools the company has had around since the start. Re-Tooling a company or a team is unlikely to ever happen because of the drop in productivity. Commented Oct 27, 2011 at 15:46
  • 1
    +1 for plan and implement incrementally. rewriting everything is just asking for failure. Small wins over time build confidence. As for specs... most of the specs you get as a programmer will be lacking its our job to refine them. Every once in a while you get spoiled by someone who writes good specs. The usually get moved/promoted/find a better job far to quickly as far as the programmer is concerned. Commented Oct 27, 2011 at 19:41
  • @Loki Astari: At most companies I've been at I have pushed through changes to ranging from the revision control system, framework, development process to even language. All you need is a reasonable plan than outlines what the cost and benefits of the change will be. Just because it's rarely done, doesn't mean it can't be done.
    – snakehiss
    Commented Oct 28, 2011 at 3:37

Speaking from experience: It's not easy. It's almost impossible. Management doesn't care that the code sucks and more than likely are completely ignorant and/or clueless of the issues being faced, or they would have fixed it long ago and you wouldn't be stuck with it today. The best thing you can do is to make a list of the reasons the code sucks, and then the reasoning behind why it sucks to demonstrate actual business value in refactoring/rewriting it.

An example might be for "Code is not maintainable":

The current code is not maintainable because of X, Y and Z (list reasons why it's unmaintainable). This makes change requests and new features very difficult to do, because X, Y, Z (reasons why making changes is difficult). Because changes are hard, the development team can't easily respond to bug fixes and improvements.

Your only hope is that your boss and senior management aren't too stupid to understand what ramifications that has for the code, and are willing to stop coming out with new feature requests to address the issues, otherwise your efforts are going to be in vain. Speaking from past experience, it's very likely that they won't see anything wrong with the code, and/or your co-workers are too spineless to bring their concerns to management.

Good luck. You'll need it.

  • 2
    Agree and "not maintainable" also works only to some extent. For many managers (especially without technical background) working code equals to maintainable code. If you claim otherwise, you could be even seen as incompetent in their eyes.
    – MaR
    Commented Oct 27, 2011 at 15:59

"I started fresh out of college" -- should answer your question.

The management probably know there code is sub-optimal. Most code is unless you hired Ray Gosling, Guido Van Rossum or someone else really good and expensive to write it.

The management also know it works using whatever definition of "works" applies to your company (Doesn't crash, sells , delivers the reports or whatever).

They want you to keep the code "working" at minimal cost. They don't want a proposal for an expensive project to re-write everything.

  • Your first line is totally biased against juniors. For one, you don't know HIS experience so you can't conclude an answer to his question. And generalizing as such is being extremely biased against juniors! I've been at it for about 20 years now and I can guarantee that I've seen more knowledgeable 'newbies' than 'senior ignorants'.
    – Jeach
    Commented Nov 1, 2011 at 19:22
  • Not exactly biased against juniors, but, perhaps he should acknowledge the experience and superior knowledge of his colleagues who have been working their for some time? They cannot all be incompetent old Wallies. Commented Nov 2, 2011 at 1:37

The business case is almost impossible to make because your deliverable is working software (what they already have) not elegant code.

Add in the fact that in software there is a big opportunity cost from getting to market with features first. If you really think about it, the long term payback on the time investment isn't guaranteed.

That said, it is still a good plan to refactor and fix the small things (like getting a good VSS) along the way in manageable bites. Ultimately this is a technical issue not a management one. Just do what needs to be done while still delivering on what you promise and you will be fine. Management probably isn't going to be interested in the nitty gritty details of code quality even if you make a strong case.


Just leave as soon as you can (maybe don't leave too soon as you don't want to look like a job hopper). The fact that they code is a mess and people are staying there means you are likely working with poor developers. Any decent developer who cares about their work wouldn't stay long working on such crap.

The chance of a rewrite occurring a pretty low unless you can very clearly demonstrate it will be worth the investment $$$ wise.

  • This is, in the end, the only real course of action. I've said it before, I will say it again: Smart developers work for smart companies that understand why it's important to ALWAYS write good code and devote the necessary time to ensure good code. Lousy developers work for lousy companies where everyone is too focused on "getting their tasks done" to care that they're just adding more mud onto the pile and even see refactoring code that isn't directly related to your current task to be "wasting time". These places aren't worth working for if you consider yourself smart. Commented Nov 11, 2011 at 15:49

Management do not care about the code. They care about having a product to sell.

If the legacy system is really, really bad and it is adding a ridiculous amount of overhead on for the majority of the team (I say majority because there's always a guy who either coded large chunks or all of it and knows it like the back of his hand) then approach them and say it's costing the business money in development time, and it'll have a knock on effect with customer satisfaction.

But once again, they still don't care about code, they care about a product, so whilst that answer might make them go "Yeah lets do it", you might as well tidy the code up without seeking the permission of a manager. Don't go overboard, make sure you talk to the team first, no one likes to come and try use that function that took you 3 months to write and now appears to not work because it's been hacked out.

  • As you hint to...There has to be something he can do to improve the code. If its all one giant function there are things you can do about that. The fact he even complains about Source Safe is sort of funny. There is nothing wrong with Source Safe, it was used for years, it might have a few things that makes no sense in today's world but thats hindsight.
    – Ramhound
    Commented Oct 27, 2011 at 18:19
  • I think SourceSafe itself isn't the issue, it's continuing to use SourceSafe when there are better free tools available just screams "We are ignorant of everything outside the box" and "Mediocrity is the rule of the day as we will stick with an inferior product rather than learn a superior one". It's the attitude that most SourceSafe users have that is the problem. Commented Oct 27, 2011 at 19:39
  • "tidy up the code without permission" -- sounds like fixing something that ain't broke. Commented Nov 1, 2011 at 1:36
  • 1
    My living room isn't a health hazard but I still make sure I clean it on a regular basis. Not so much a case of fixing something that isn't broken, but doing a needed task. Commented Nov 1, 2011 at 9:41

Approach management in such a way that you show that you understand the budget impacts of making big changes to the code and the budget impacts of NOT making the changes. I liked Emilio's wording.

It's important to keep in mind though that "old" code will always be awful. By this I mean, we all grow as developers constantly. We write good code, then learn to write better code later and the previous "good" code seems terrible. Too many developers get caught up in constantly trying to make it better and waste more money in the long run. It's a balancing act. That being said, it's always great if you can make it better as you go. When you go to modify that giant function, split it up! Eventually you'll get somewhere.


Don't do it.

Rewriting a large project from scratch is a big mistake most of the times anyway.

  • Large is relative.
    – Luca
    Commented Oct 27, 2011 at 23:01
  • 1
    My definition is: If can't rewrite it yourself in 5 days then it's large. Commented Oct 28, 2011 at 15:31

I've never thought it is easy to tell managers especially Project Managers about bad code and refactoring. First, they must trust you, even if you are senior guy you still need time to be trusted. Second, they simply don't understand how bad the problem is. If today is the last day to release a new build, and the build fails. They know how serious it is, but they never know the build just failed because lots of problems such as bad code, inadequate testing etc.

I've been done configuration and deployment tasks in a web project. It often takes much time to fix unexpected issues each time I deploy a new build. Most of issues were security and integration (between several web/Windows applications). Our code sucks, others' code sucks, they're completely spaghetti code.

We were planning for a new version and I strongly asked for some refactoring, just add detail log to login/authentication code where bugs often occurred. Managers agreed, but then it was put in a nice-to-have list and I don't know if it will be done since we already had a big list of features and a tight time frame.


There are two kinds of managers: ones that pretend to understand what you do and those that don't. The ones that pretend to understand software will be hostile to you. The ones that don't are merely annoyed by you.

In any case, managers are all liars so they have a strong disposition to assume everyone else is.

My point is, if you say the software is out of date, they'll just take it as an excuse. They don't care.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.