6

I'm working on a legacy software project right now. It consists of a lot of mostly undocumented classes. There are no unit tests and the project has enormous technical debt (copy-paste classes, missed abstraction opportunities, 100 liner methods and 5000 liner god objects...). There are two other programmers in the team who are working on the project since the start. There were some other developers working on it but they all left (for reasons unbeknownst to me).

I was chosen by the management after an interview because I use/used TDD in my work, I have in depth knowledge of unit testing and I'm willing to work on a web application which has humongous load on it. Based on the interview I thought that they are putting the industry's best practices to good use but in fact it is quite the contrary.

My problem is that I either have to spend a lot of time on a feature in order to make it work or risk introducing a bug because the existing code is hard to test properly. Since I lack documentation and my teammates aren't really helpful either I sometimes step on "mines" left in the code by previous developers (undocumented side effects mostly or hidden rules which only someone with in depth domain specific knowledge can know of). These together began to reduce my reputation towards the two other developers I have to work with.

My question is how can I convince the management/other developers that we need efforts to clean up the technical debt and write documentation for the features so a new developer on the project can get going easily? Given the situation above they don't really trust me and I have no options to justify any ideas I have because we have no metrics/code quality tools/management tools which can be used to objectively assess the situation. From their perspective everything on the project is just good enough.

closed as primarily opinion-based by Jim G., jmac, jcmeloni, gnat, IDrinkandIKnowThings Oct 30 '13 at 13:52

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • The only management we have is a CTO but he is not a programmer and I think that although he knows about the situation he does not feel the weight. I have the feeling that the others don't want me to press on this matter and/or try to make me look like someone who is problematic. – anon Oct 28 '13 at 19:55
  • What level are you at, relative to them? Are you in a position to enforce a "do it the right way" edict? – Adam V Oct 28 '13 at 20:05
  • I'm working on the project as a senior developer. The other 2 guys are seniors as well and we have a junior developer. There are other developers but they don't work on this project. In theory we are at the same level with the others but they are really hand and glove with each other. If I came up with an idea they often tell me that they know better because of their domain specific knowledge effectively vetoing my ideas. – anon Oct 28 '13 at 20:10
  • Was the CTO the one who brought you in? – Adam V Oct 28 '13 at 20:14
  • 2
    "more than 100.000 classes" Whomever designed this should be blacklisted so that they never get a job in IT ever again. – user10483 Oct 28 '13 at 20:25
6

I've been through this before (and I'm working through the tail end of it now), so I'll share a few things I've learned along the way.

You are not alone.

IME, the situation you've encountered is the rule, not the exception. I think you're tremendously privileged that you've managed to become a senior developer and have never encountered this. I think that part of your frustration is you're holding your actual team up against the idealized version of a team from the blogosphere, and the complete mismatch makes you question your sanity or theirs.

You need to throw out all your assumptions about what will and won't motivate your teammates, what they know and don't know, and especially you can't assume they'll just take it as read that they should follow good practice.

Your problem isn't technical, it's political.

The reason there aren't any standards is because no one wants to be responsible for creating, maintaining, and enforcing them. The reason no one wants to talk to anyone is that they can't imagine a world where they do anything differently, so what's the point of talking about it? No, I don't understand how you have a team of programmers who can't imagine different ways of doing things, but I've seen it often enough that I know for sure such teams exist.

To resolve this, you're going to have to assume some sort of leadership. This is politically difficult, because you are the newest member of the team.

You need to win trust.

The first thing you need to do is build trust on the team. I'd suggest starting with management, because I think your coworkers are already finding you threatening to their cozy world view.

Really listen to everything he says about future plans and expectations for the software. I think you'll find that you have openings for "You want me to do X, but this is in conflict with the existing practice on the team to always do Y. Which is the priority?"

Be alert for places that requirements are just getting dropped because everyone involved (including your CTO) sort of knows where the mines are and subconsciously sidesteps them. These are places where you can step forward and say "I think if I too two weeks to refactor this subsystem, not only could we do that requirement that everyone says is so hard, but I think I can probably fix recurring problem Z." And this is how you get to have your own rock-solid subsystems like Adam V suggested.

Once you have a rock-solid system, leverage it to be able to provide accurate estimates--something I guarantee your teammates can't do. Nothing endears you to a manager like giving him estimates he can take to the bank.

Be aware that this first step of getting your own subsystem will be much easier than getting other people to change, so don't get overconfident when it happens. Equally, don't get overly discouraged when you realize that everyone is quite happy to let you do what you want as long as they don't need to do anything differently.

Learn the current system

You're not going to know where you can confidently refactor until you've gotten at least a basic feel for the current system. I think at least part of your problem is that you were deceived by the interview process by thinking you could just jump in and start writing good code and get complete support.

You need to figure out how to work within the current coding style at least long enough to develop some domain knowledge and a feel for where the mines are. This will also allow your coworkers' hackles to go down a bit. Learn to use grep and other tools to find those "hidden" minefields. No matter how bad code is, there's usually a way to find a thread and pull it out far enough where you can find the other end. Look at this as a way of developing those debugging skills in ways a "better" team could never hope to provide you.

This will show you where "seams" exist that you can tie into or places that seams could be made with relatively low risk.

Clarify expectations

Go back to the person who hired you for your TDD and other expertise. Don't gripe about how you're not even able to even use these skills. Instead, ask questions that give you insight into this person's thought process. They probably think your course of action should be obvious (either because it is to them or because you're an expert in one area and hence should be expert in everything so it should be obvious to you), and you don't want to disappoint them and wind up getting fired.

Some example questions I might try in your shoes:

  • The existing team isn't using Test Driven Development. Did they specifically ask for someone to be hired with these skills?
  • What sort of timeline are you thinking I should be looking at to try to implement these new practices?
  • How much support are you willing/able to give me in instituting this change?

etc.

One thing that I realized in my own situation is that, just as I sometimes don't have a clear understanding of how my manager envisions these things playing out, he often doesn't know what I need from him either. So if I send out an email to the team asking that we change practices, I might follow it up with an email to him asking for his explicit support and tying that to a specific goal he has set for the team.

This process takes time

It can take up to two years to build your credibility on this type of team to the point where you can start to shift the culture. So if for whatever reason you know now that your time frame with this team is shorter than that, you may want to consider moving on to a team that has better appreciation of what you bring to the table. However, if you stay and manage not to get fired as a bad fit, you will learn rare and valuable people and leadership skills that will serve you well into the future.

TL;DR

Often, whether a suggestion succeeds or fails comes down not to what you say but how you say it. I find that asking lots of questions works for me. "If we take this approach, how does that affect our ability to add feature A that we know is coming?" This leads people to the answer themselves and helps you avoid looking arrogant. Even more importantly, unless you are completely perfect you will be wrong some of the time. Asking these types of question gets to the meat of the matter without everyone taking a stand they then have to defend, so you don't wind up with a position you've fiercely defended where you turned out to be wrong.

I find in particular that phrasing things "Why wouldn't it work to do B instead of C?" works very well, because it puts the onus on them to come up with justifications for why you can't do something. For the team you've described, likely this isn't their forte. However, even if they can completely shoot your idea down, that's terrific! You've gained valuable insight into the problem, and you can make a different suggestion.

  • THere are systems which are unfeasible to apply any TDD because its intrinsic techonolgy architecture doesn't allow it. – lambdapool May 10 '16 at 14:09
8

I think there are a few things you could do.

Fix one area to be excellent.

Find one area of the code to focus on - something where either there is a lot of new code being written (so that you can influence all code going forward) or where there are a lot of bugs being filed (so you can justify rewriting everything that's failing). Talk to the appropriate manager or the CTO to get permission to keep everyone else out of that area and route everything to you.

For that one area of code, do everything exactly the way it should be done - proper design patterns, error handling, unit testing, etc. Ensure that your unit tests run every time something changes, and the system emails you (if not the entire team) when something breaks.

The outcome of this must be that the code you write is visibly better than the surrounding code - less bugs, faster to add new features, better documentation, etc. If you can't deliver that, then you'll have no leg to stand on when you push for future development to follow the same pattern.

Push for a zero-defects methodology.

See if you've got support for a rule that states that you must fix all bugs before you can write new code. Then, when your coworkers are writing buggy, anti-pattern-filled code, you can file bugs against it and keep them rewriting the same code over and over, while you're making progress on your bug-free and well-designed features. As Joel says,

At some point, one of these geniuses will spend two weeks writing a bit of code that is so unbelievably bad that it can never work. You're tempted to spend the fifteen minutes that it takes to rewrite the thing correctly from scratch. Resist the temptation. You've got a perfect opportunity to neutralize this moron for several months. Just keep reporting bugs against their code. They will have no choice but to keep slogging away at it for months until you can't find any more bugs. Those are months in which they can't do any damage anywhere else.

(In fact, the entirety of Joel's "Getting Things Done When You're Only a Grunt" is full of useful tips in this situation.)

Push for other appropriate rules.

Constantly-increasing code coverage? No new code without associated unit tests? All code passes QA before it's accepted? Find simple rules that will help the most, yet are the hardest to fight against (who wants to tell the boss "it shouldn't matter that QA thinks it doesn't work correctly"?), and push for those.

Leave (if necessary).

Keep in mind that the company has gone this long without seeing this as a problem, despite all the symptoms (buggy code, developers leaving, etc.). It's entirely possible that no matter how reasonable your arguments, they're going to see you as "not fitting in" and it can color them against you. So take that into account - if you're really interested in staying and trying to turn things around, perhaps start out with less objectionable ideas and work your way up to "fire the people who are causing the problem"; if, on the other hand, you're not interested in staying unless they clean up their act, you can be blunt and tell them "this code is a festering pile, and I can't keep working here unless you do X, Y and Z to give me the power to clean it up", with the understanding that the answer is likely to be "okay, nice working with you".

Good luck!

  • 3
    I would be incredibly cautious about constantly reporting bugs against a developer's code. It may strike management as spiteful, counter-productive, and focused on minutiae instead of the big picture. It may be more effective to point out the large quantity of bugs that get introduced, hire a proper QA tester, and have a third party find them all (including looking at your code) to give the appearance of being unbiased. – jmac Oct 29 '13 at 0:21
  • You're probably right. If you can get a third party to point out the bugs and inefficiencies (and be listened to), you're more likely to gain credence when their findings match what you've been warning about. Based on the OP's writeup, however, I'm unsure whether there is any QA, or whether QA has enough pull to point out problems or be listened to. – Adam V Oct 29 '13 at 17:57
  • 1
    If you remove the final paragraph I would up vote this answer. Leaving will not fix the problem it just takes the OP away from the problem but creates new problems. – IDrinkandIKnowThings Oct 30 '13 at 13:55
  • @Chad - that's true; however, there's only so much dysfunction that a given employee can take before hitting their breaking point, and recognizing when you've reached that point is important. Once you're there, the right thing to do for you is probably to move on, even if it does not solve the company's problem. – Adam V Oct 31 '13 at 19:51
  • The point of coming here and asking the question is how do I deal with the problem not escape the problem. By adding the you should quit you ruin an other wise great answer. – IDrinkandIKnowThings Oct 31 '13 at 20:04
4

My question is how can I convince the management/other developers that we need serious attempts to clean up the enormous technical debt and write documentation for the features so a new developer on the project can get going easily?

You don't.

What they have works well enough for them. Your job is to show that better code lets them do more (and thus make more money) and/or with higher quality (to keep paying customers) and/or with less work (and pay less developers).

"Ugh, this is so horrible" doesn't work, because non-technical people don't see it. All they know is that the code runs well enough and makes them money. Sell to management that things being better provides tangible benefits.

There were some other developers working on it but they all left

It also might be worth pointing out that your developers wouldn't keep quitting if the codebase wasn't a steaming pile... that leads to the Dead Sea effect and spirals into what you have now.

  • Enh. Sell the idea, worry about measuring it later (or let this be leverage to get at least JIRA and stuff used). Though I expect a full refactoring effort to be too costly based on your description, regardless of its benefits. – Telastyn Oct 28 '13 at 20:36
  • +1 for linking "the Dead Sea effect" when discussing what sounds like one of the finest examples of said effect anywhere in the world. – Carson63000 Oct 28 '13 at 23:41