I'm a newly graduate programmer and just got hired before my graduation. In the office, I used to create and revise modules of some applications developed by other programmers in our company. The problems I encountered with their applications are:

  1. Unnormalized database at it's best, they've broken all the rules of database normalization, Codd must be angry.

  2. 50% of the content of the database is literally NULL (they should have default value I swear).

  3. One stored procedure is used in all database transactions, full of "if-else" statements.

  4. They are reinventing the application settings in .NET WinForms, they create their own file which contains everything they want. I think they are very fan of VB6 or maybe they don't study really, they're guessing how to achieve something.

  5. No error handling! Clients sometimes report "Exceptions" which they shouldn't be seeing.

  6. Web files and Windows Forms are not organized or grouped according to their use.

  7. Naming convention, there are Camel case, pure lower case, with and without underscores and abbreviations.

  8. Bad programming practices like database transaction in each iteration of a loop.

  9. They developed website with SQL injection in mind, they welcome them.

  10. HTML elements were not used according to their sematics.

  11. CSS are not optimized for different browsers.

  12. They include several versions of jQuery in one HTML!

. . .

N. Many more!

The worst thing is, I felt being blamed for it's fragility. I mean, when I add code, there are times that it ends up with error, sometimes because they did not create constraints or they allowed duplicate data. The system is so fragile and dependent to one another, it's like walking in a field with landmines! (THIS HAPPENS SOMETIMES, THIS IS NOT THE REAL ISSUE)

What should I do?

  • Ask the experienced developers how to avoid errors when adding code?
    – user1249
    Aug 16, 2011 at 8:21
  • 4
    "The worst thing is, I felt being blamed for it's fragility. I mean, when I add code, there are times that it ends up with error. The system is so fragile!". At the moment you are just upset because you made a mistake and now you try to blame the system for it to avoid shame. No human ever wants to be guilty. We always look for excuses. Get used to the system and get used to making mistakes. Like @Raynos stated, it'll be the same almost everywhere.
    – Falcon
    Aug 16, 2011 at 8:52
  • 2
    @Falcon "almost everywhere" such a statement makes me hate our industry, can we have a revolution?
    – Raynos
    Aug 16, 2011 at 8:55
  • 2
    @Raynos: I'd rather not discuss this here in the comments section, you can talk about that a whole day imho. I think agile processes, DDD and refactoring help a lot on keeping your software in a good shape. But I have witnessed far too often that management opted shortsightedly for the cheap, quick and dirty solution to maximize their ROI.
    – Falcon
    Aug 16, 2011 at 9:00
  • 6
    Um, duh? Organize it, preferably after speaking to your manager and getting permission. This isn't a question, it's a rant.
    – Aaronaught
    Aug 16, 2011 at 12:25

12 Answers 12


If you're a newly examined programmer - don't suggest The Grand Rewrite. Improve it little by little, step by step. You're begging for trouble rewriting the whole application. I find that the biggest hurdle to choosing incremental improvement is in one's head - "how can we possibly clean up this mess?" But more often than not, it's easier than you think, just take baby steps.

  • Thanks! That's exactly what I'm doing now. I'm just afraid it would take a lifetime to do that. Actually I'm rewriting it without telling my boss, is that okay? I think I'm just wasting my time.
    – kazinix
    Aug 16, 2011 at 8:48
  • 1
    @domanokz your welcome to re-write it as a prototype in a stack your highly skilled with and can just get it done. Then show of the prototype and recommend based on real facts (time, test coverage, prototype) that it can be rewritten and that's it's a financial gain.
    – Raynos
    Aug 16, 2011 at 8:51
  • 13
    @domanokz If it's during work hours, no. If it's in in your spare time, no. ;) During work hours you should do what is asked of you - you don't have the mandate to choose the tasks you seem fit (yet). If you do it in your spare time, stop. Some will argue that it's a learning experience, but way too many hours have been spent working for free in this profession - if you want to learn, do something for yourself.
    – nillls
    Aug 16, 2011 at 9:00
  • The one step at a time is always good. Concentrate on one improvement at a time, and finish it from front to back. Most importantly - /don't tell management/. They don't need to know, it's not their problem or their pride and quality of work on the line, it's all yours.
    – cthulhu
    Aug 19, 2011 at 21:43

I think the best thing that you can do is to set with your team members and discuss the issues you listed with them.
It shouldn't be about blaming each other, neither it should be pulling hair sessions. What is really matter is the project itself. You should all keep this in mind.

Talk with them about the decisions they made, maybe there is a reason (who knows?)

Also keep in mind that you are newly graduated programmer, so you shouldn't generate the impression that you consider yourself better than your team members. Because many new fresh graduated persons fall in this trap.

Use (innocent or not so innocent) questions to expose the fragility you are talking about.

  • Yeah, I'll keep that in mind.
    – kazinix
    Aug 16, 2011 at 8:37
  • This pretty much sums up what i was going to say. I will add though, have these issues ever been brought up before? Maybe someone else realizes these mistakes, but they just haven't said anything because of fear. Fear of what who knows? But security issues like SQL injection is bad. Honestly being a recent graduate or not, you should speak up. Just ask in good manner if there is a reason for this or that and why not do x. If they don't want to listen to your suggestions then find another job. You will grow to hate it if you think your input doesn't matter to them.
    – Matt
    Aug 16, 2011 at 10:20
  • Most warts are bugfixes....
    – user1249
    Aug 16, 2011 at 13:29

Grab the low-hanging fruit:

I would start with security vulnerabilities. Tell your boss that you are worried about SQL-Injection, and them demonstrate how an attacker would gain access to the system. Once they are worried, tell them you can fix the problem.

This will give you credibility, a commodity that you'll have to have if you intend to implement change. Next,

I'd talk to other developers (and maybe your boss) about putting error trapping in the program, explaining that it will help in support of the software if you knew where and why things were breaking and make the company look better.

I've been in a similar environment, and this is what I've learned.

  • Assume an attitude of a student, and never have a superior attitude. Some well-asked questions can cause the other developers to consider ideas they may never have even heard before. As the junior developer, you'll get further with low-key, subtle influencing than bold strokes.
  • Never insult developers or their code. Your goal is serve the company and your customers by implementing a sea-change. Making enemies will work contrary to that goal.
  • Remember the line about how to eat an elephant by doing it a bite at a time. Small incremental steps will allow the organization to digest the changes easily, without heartburn.
  • Don't forget that theory and practice are not always the same. While there is no excuse for most of what you described, there are times when business needs trump design theory. For example, fully-normalized data may be too slow for the needed performance.
  • +10 if I could, great answer, and a sensible plan of action for the OP.
    – ozz
    Aug 16, 2011 at 14:04

Find out what led to this application and attack the reason

On a purely technical level, you already know what to do: normalize the database, add constraints/defaults, refactor the stored procedure, etc, etc.

But, in my experience, this is only circumstantial. The real problem is the Environment that produces such a mess.

And there may be different reasons.

  • One could be that the team honestly does not know better (I mean, for each of us there was a time when we didn't). In this case, you could carefully try to educate them. The objective here would be to sensitivise them to their wrongdoings, so that they too see the application and not you as the problem. The danger here is to come across as 'the nagger', so be careful to criticize the code, not the person.

  • Maybe they feel forced to code quick and dirty. In this case, try to establish that excellency pays off. This is in my experience done best by example, and by standing ground where quality is about to be sacrificed.

  • the hardest, and in my experience most common scenario is they think it's 'pragmatic' and best practice, due to groupthink and little exposure to quality. There are many proposed solutions to such a scenario (often quoted 'how to get things done as a grunt'), but in my experience, that does not work: when your new code causes a weird side effect, you get blamed for not having memorized all their weird dependencies ("you cannot call the date function inside the customers module, you need more discipline"), and not the... "programmer" who thinks 'loose coupling' is for hippies.

To quote someone: "Things are the way they are because they got that way ... one logical step at a time". Your problem is not the denormalized database, your real Problem is the Team's justification for it.


I would try explain to two of my seniors in a meeting (one programmer, one not) that it's badly written and that it would probably save your employer money to let you rewrite it now and reduce maintenance work in the future, than attempt to keep maintaining it as it stands.

  • That's a nice suggestion... Sir, I'm a newly graduate programmer, I don't think the boss will believe me. Anyway, I'll try that.
    – kazinix
    Aug 16, 2011 at 8:26

Quit this job. I've worked on a similar project (except database was OK, but the whole application contained like 3 real classes, all CRUD code was like Issue.Create (50 parameters here) and IDictionary<string,object> Issue.Get(int id)), put some tests in, wrote new functionality in clean fashion but decided I want to do something else with half of my life.

  • 1
    A pragmatic one :) Aug 16, 2011 at 8:47
  • 2
    @domanokz It's cool (and profitable, too) to be a part of task force to clean the mess, but it's really demoralizing to work in environment where nobody cares.
    – synapse
    Aug 16, 2011 at 8:47
  • 1
    @damonokz Sorry maybe I misunderstood something but you said "Anyway, its a relief that somebody understands the situation". So the guys here who are trying to answer your question and spending their own time don't understand the situation?
    – Chiron
    Aug 16, 2011 at 8:49
  • 2
    @domanokz it's not a question of running away from problems, it's a question of whether you want to spend your time working with people in such situations. Simply put the development atmosphere is not top-notch, if it was you wouldn't have a code base in a such a state. If it were me I wouldn't settle for anything less then a top-notch development atmosphere. Then again financial sustain can be more important then ideology.
    – Raynos
    Aug 16, 2011 at 8:49
  • 1
    IMO, "Quit this job" is a cop-out, easy-to-say-from-the-anonymous-Internet answer. That's not to say I don't understand the reasoning, but choosing to stay or go has to be a very personal decision (we certainly don't know the whole story, or whether his personal life would even make this possible, or...). Aug 16, 2011 at 13:14

I hate asking this question because I seem to have been asking it a lot lately.

Is there a local coding standard in place? If not, would you consider drafting one, if nothing else to deal with some of the more stupid problems like a) naming conventions b) acceptable error handling and non-standard use of languages?

Do you have any sort of a bug tracking system so that when you make some change and it highlights some pre-existing bug that you can track all these things?

If you want to stay there, you cannot hope to fix all of the problems at the same time. You need to look at two options 1) prevent broken stuff in the future - imo this may be higher priority and 2) start fixing previously broken stuff. I don't know how big your code base is but my money is on this: you will not get it all re-written in the short term and if your next year consists of rewriting broken stuff you're going to want to leave anyway.

I'd be leaning towards moving if there are any other viable alternative options. If not, give yourself a time frame to see how things shape up and then make a decision about whether to stay or not.


You basically have two options:

  1. Get a new job
  2. Make your current work environment better.

option 1. is self explanatory, but for option 2, that means being a good programmer despite everything else going on around you. Religiously stick to good practices and conventions. Try to make these conventions fit in with what already exists as much as possible (especially on things where it doesn't matter too much, like naming conventions - there is no point in doing anything wildly different to what has been done before else you'll end up in this situation: xkcd)

One thing that every one hates (regardless of actual truth) is being told that what they've done is useless; especially by a young, inexperienced junior (I graduated 3 years ago, believe me, they really don't like it). All you can do is lead by example. If you are unlucky and no one follows you, then at least some areas of the code that you work on will start to improve, if you are lucky, some may even continue what you've started... Joel Spolsky has a good article on this sort of thing, there are loads of other great articles on his website too.

Remember as well: no job is perfect, no one writes perfect code and sometimes it is not immediately obvious why a particular piece of code was written like it was.

Do your work well and listen to what other programmers (especially those you work with) have to say. If you aren't sure about their advice, then ask questions, just keep them dressed down and never use them to imply you don't think the current system is very good. Keep questions simple and expect a rational answer to them, that way you won't get people's defenses up and either you will get the answer you needed or you will be congratulated for spotting a flaw / problem that no one else though of.

  • I know, sometimes my job is more about the art of diplomacy; improving existing stuff without suggesting that it needed to be improved!
    – Amy
    Aug 16, 2011 at 9:26
  • (Generally) More experience programmers do know better! Always assume they do, I've learned far more that way and good programmers far outnumber the wallies!
    – Amy
    Aug 16, 2011 at 9:31

Suggest code reviews to your lead programmer. This will provide a non confrontational environment you can criticize the code. Also it will help you pick up techniques of building stable code in a fragile environment.

  • There is no lead programmer, the management itself is spaghetti system.
    – kazinix
    Aug 16, 2011 at 8:25
  • @domanokz Suggest to those people apropriate (ie your line manager?) You can spin it as something to help your development Aug 16, 2011 at 8:30
  • 3
    you're not really selling this company as a good place to work to be honest.
    – temptar
    Aug 16, 2011 at 8:43
  • @domanokz Depending on how ambitious and prone to taking risks you are: why not try to get Team Leader?
    – keppla
    Aug 16, 2011 at 9:36
  • @keppla for a new graduate to ask to be team leader is a bit arrogant Aug 16, 2011 at 9:47

Addressing just the specific issues you mention: the serious ones are 5, 8 and 9. Users should not see exceptions, the bad practices with transactions will be hurting their performance (unless there's a good reason for them: check this before starting on tackling it) and SQL should never ever be injected. In fact, the fact that the application is vulnerable to injection attacks also indicates that it is slow: parameterized queries are quicker because the database can know for sure that they are values and doesn't have to check for complicated nested joins, etc. Safer, faster, better user experience: these are things that it should be possible to persuade your colleagues and managers of the real value of.

The other issues, while probably maddening (I emphasize that I don't know javascript so can't talk about the jQuery point), are things where you will probably have to just lead by example. Make sure that what you do is clean and easy to use and understand given the rest of the codebase: the goal should be that fellow developers can take up what you do without extensive training, and users can do it with (next to) no training at all. (Well, within the scope of what the user base is. Don't make it worse is what I mean!)

  • "parameterized queries are quicker because" - hold on, how can the sql server tell whether a given string constant is from concatenation (vulnerable to injection) or simply included literally in the query (not vulnerable to injection? Also, why would it need to check what it sees as a string constant for "complicated nested joins"? Are you mixing up parameterized queries with prepared queries?
    – Random832
    Aug 16, 2011 at 13:26

And just to add my 5 cents - from something like 20 years of experience, working for different people (many) and having others worked for me as well (or my team, whatever).
I'm leaning towards what the nillls said.
a) if it's too chaotic, I guess you could quit the job - but that's not the answer - you won't be finding too many 'ideal' companies or old-code, it's always problems, either people or code,
b) work with it, the code, and with them, the people - slowly, try to assert your 'standards' (or any standards in this case : ) - and explain, talk w/ them.
c) don't try overhauling everything - as you can as well quit the job. Usually ends up bad - or worse everything ends up your fault, even if they're susceptible - you don't want that much responsibility, especially being rookie
d) try to understand why it's like it is - often, there's a real reason why real-life code is too messy - too little time, too many programmers etc. It's best if you can work 'with the system', explain with arguments (that what you're doing is going to save the money, maintain etc.). Also real projects are never fun - and people actually investing money hate to get suggestions from someone interested in making things 'beautiful' - that's what their side looks like - you need to make your case - and basically good s/w is what saves money, short or on a long-run, so work in that direction.
e) forget about coding 'properly' or getting kicks out of it - look at it as the job - you obviously have the necessary tech background - try to learn the ropes w/ these jobs - real pains, dealing exactly w/ situations you're in right now,, that's what most jobs are about, at least what I've seen : )
f) and practical, coding advise -
do 'facade' your code - db or otherwise
separate parts that you're doing from their code
I've learned that and that oftne works nicely - you have to integrate some parts, but given C# and all you can easily separate things.
...so, if you don't like db code - do a small 'layer' that you'd be using - for start, just copy and change things slowly - but you'd be building it properly, structure, safe standards and all (not always possible, but most of the time)
...that way also, you'd be able to separate from the errors a bit
if it's not relaly your error - then you should be albe to make a case of it actually use that in your advantage to show them why old code makes problems, while your new one is working perfect
with around db that's harder (inside the db, design) - but you can always try and aks for, change things slowly, field by field, index by index etc.
and so on in this direction
and btw. this isn't the worst job in the world, get the best out of it, you can set your own standards, make bigger impact, learn other things


When the code looks right, the logic is right.

The process of reformatting and refactoring code you are charged with fixing/changing is an effective technique for catching logic errors and unhandled corner-cases. 'Facading' code that your code depends on (see Gaga's answer, point f, for details), is a practical approach to cleaning up code for the current use. Creating wrappers or even a parallel API layer can be a reliable way to evolve the code base while maintaining backward compatibility for dependant code that can't be changed yet.

On mainframe and other "legacy" systems where downtime is not an option, where the most modern tools and languages are often not available, and where new hires often find themselves while they "learn the ropes," code-maintenance techniques like these can be vital to success.

(extensively revised from original based on feedback below)

  • So what if everyone in the team does the same? Mar 12, 2013 at 16:18
  • Programmers, like cooks, are individualists. Give each team member responsibility for certain parts of the development. Then pass that part to someone else for review or further work... like an assembly line. A given part will be worked on by a series of people. The team collaborates as needed on the interfaces, best-practices, and minimal style standards so everyone can understand the code. For maximum incentive, each person should be able point to some part and feel proud of their accomplishment. Mar 12, 2013 at 18:56
  • The assembly line analogy was a terrible example. There's no space for "freestyle" in an assembly line. Mar 13, 2013 at 9:42
  • Working in a team is hard, understanding/debugging others' code is hard work. You're just making excuses to avoid it. Good code has to be readable/maintainable by everyone, there is no space for ego in software development. Mar 13, 2013 at 9:44
  • Unlike a factory, programmers design their "software assembly line" as well as use it... so lots of creativity and experimentation. You're absolutely right on your next points (except the "making excuses" part, of course). Balancing the psychological needs of the members with the objectives of the team is what makes successful project management so difficult. Ignoring either guarantees project failure in my view. Mar 13, 2013 at 16:43

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