What to do with a not well organized application? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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!)

Answer 11

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
Best

Answer 12

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)