What is the/Is there a right way to tell management that our code sucks?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 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. 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.

Answer 4

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

Answer 5

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

Answer 6

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.

Answer 7

• 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.

Answer 8

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.

Answer 9

"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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

Don't do it.

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

Answer 15

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.

Answer 16

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.