Owning Up Bad Code

Question

I am moving out of my current company to other opportunities elsewhere. As I was looking at my code base, there were some portions which I had written when I started programming. These screamed 'LOW QUALITY' (not that I write excellent code now, but certainly better code). After I leave, the code would be taken up by my colleague who works at remote location and who until now was using my software for her work. We have been working together for over two years.

Should I write to her that when she happens to see some files, it might surprise her? Should I warn her about the bad quality and request to bear with it?

P.S.: A recent question in SO prompted me to ask this, that discussed the opposite scenario described in my question. The OP was looking at bad code and wondered how person 'X' could write such code.

Answer 1

Nah, people always expect other people's code to be horrible. She won't be surprised.

Answer 2

I think it would be nice to do this in some form - either by writing to your colleague or just adding some comments to the code. I would suggest you:

• Explain the reason (inexperience at the time of writing)
• Any "gotchas" you now realise are in the code, but which someone just reading it might not know about
• How you might suggest refactoring it into something more sensible

There's no need to make a big deal about it - just something quick should be fine, I'm sure.

Answer 3

I would just state that you were still developing your coding style when you wrote the original code. We've all gone through the stage where we see something we did 2 years ago and wonder how we could've written it that way. It just shows that you're growing.

Answer 4

When I left my last company, though, I spent about 3 weeks sitting down with other developers trying to go through all of the various projects I had worked on. I was very frank about the portions that were written well and the portions that were written poorly.

However, at the end, I think they pretty much ignored most of what I spent my last days doing with them. I now think it was a waste of time.

I wouldn't worry about it, unless you think that there is value in trying to keep a very good reputation with the programmers (not management) in the company you will be leaving. In that case, if you have time, it would be nice to add some comments and documentation about portions that need cleaning up. I appreciate having clean comments in the code about this much more than somebody just telling me "some of this code you'll see is crap". That would do more for me than anything else, if I were the person taking over your code.

Answer 5

Two bits of advice by an old guy:

1. Not every line of code you write is going to be the best code you've ever written.
2. Not every line of bad code you're ever written will be rewritten.

It kind of sounds like you're afraid of being embarrassed by that code when this other person reads it. I'd recommend forgetting it until and unless she ever mentions it, at which point you look wistful and say "I was much younger then."

Answer 6

It's certainly an interesting situation. Leaving a position knowing that you're very unhappy with some of the work you have done is never a good thing. It really seems like something you're not proud of having done, so sending a short e-mail telling her some of the code is old and you were still learning a lot, and gently remind her that she probably didn't have the best code when she started out either.

Answer 7

As someone who's maintained several pieces of bad code in my time, any documentation, help or insight into how you thought about the problem space would be most welcome.

There's nothing wrong with looking at code from years back and saying "wow, I could have done that better." You should be constantly learning and growing in the programming profession. I would be much more shocked if you looked back at your code from 2 years ago and said "wow, that's perfect!".

Admitting this is the case shouldn't be a big deal either. When handing code off to new devs I usually give the overal architecture design, notes and point to areas that are the most likely to cause bugs or could use more work if they are feeling ambitious.

No code is perfect. Pretending so is pointless

Answer 8

All good answers.

There's no harm in sending her a note gently saying the code wasn't necessarily the best. I wouldn't make a big deal out of it. That would buy into the general judgementalism that afflicts this field.

A simple note would also make less likely any possible future badmouthing that, as people move around from company to company, could affect job prospects.

Answer 9

A lot of how she reacts will be down to perception - maybe the code you're sending her is exactly the way she codes and she'll love it!

Providing her with a good overview of what you've done, some overview comments in each of the files, some simple demo code (if appropriate) would all be valuable. Anything that helps her get into it.

Any experienced programmer has seen all types of code. She may not like the code - and all developers are fussy about code - but if she can get her head around it quickly, her overall experience will be much improved.

I wouldn't get too apologetic. Just means she'll come to it with a bad frame of mind. If the code is bad, she'll see that in the first few minutes anyway.

Answer 10

No, I really wouldn't bother, firstly you'll just be "making excuses" and no-one likes that, she'll start thinking all your code is poor quality and someone else helped you write the good bits. That's if she even bothers to read your notes and go and look - most people are too busy to spend time doing that, they all think "nice, I'll do that later", and never get round to it.

No, best practice would be to edit your code - not the code itself, but the comments. Add them, sprinkle the crappy bits liberally with the intent, with notes and "todo: rewrite this cruft properly", along with small hints on why its not as good as it could be.

Such comments will be permanent reminders to everyone, at the point of contact with the code (which is exactly where you'd want to find them yourself), and will make your code look more professional and well-thought out. Anyone reading your code will think you knew his stuff even is some is appalling code, but we've all done that under pressure and time constraints.

And if you're really embarrassed you can blame it all on that junior programmer (ie you, but don't tell them that) you used to work with ;)

Answer 11

I would agree with most of these comments and add the following. You should communicate where problem areas are, and where complicated/critical areas are. Part of being a good developer is being a good communicator, and your exit strategy should communicate in ways that will help her going forward. You should go back and comment the bad areas to help, if YOU really are that embarrassed.

As someone pointed out, she may never have to look at your code. If you have improved and that code still exists, it suggests that you haven't had to deal with it. Or, it is stable enough that you are just doing maintenance.

If she does have to go into the bowels of your "learning stages", then the worse it is the more gratifying it will be when she corrects it. She can use you as a scapegoat, once you are gone, for why she is having problems meeting a date.

Learn from this as you go into your new job, and if you find some bad code and lack of documentation, remember that the previous developer could have been just like you.

Answer 12

I suggest taking coupling and cohesion into consideration when deciding what is best. Is the older work contained to some clearly separable subsystems, or does the work have system-wide ramifications? Are these pieces one could rewrite with little risk (put another way, the reason it hasn't been replaced is lack of time, not a lack of clear contract?)

If you have clear subsystems that can get replaced, then just indicate that subsystem X, Y are candidates for refactoring/reimplimenting. If there is a well defined contract (in your head) but it remains as-yet undocumented, your coworker would probably appreciate you writing the contract down over a heartfelt apology. Remember, a well defined but convoluted API/interface/contract is typically welcome over a fuzzy one that is pretty at first glance.

If your work has system-wide ramifications, enumerate those. Given that you know what you'd do different the next time around, do you also have some ideas about how to evolve the code in the right direction? What are the gotchyas that are ringing alarm bells in your head? Those are valuable things to someone less familiar with the code.

One last thing. In the past, I've left a line open for my replacements so they can contact me. In fact, when I change positions or companies, I often tell my new managers that I might need 5% - 10% time for a couple of weeks to make sure the transition is smooth. They've typically been respectful of that decision; they recognize the value of the courtesy when the roles get reversed. Note that this is very different from a two week notice; while you are at the old job, they never really assume all you your duties. So it almost makes sense to cut the two week notice to just one week, and have a couple of semi-utilized weeks at your new job.

Answer 13

Poorly written code is not "bad" code

Code is code. Poorly written code is hard to debug, difficult to maintain, and easy to break, but it's not necessarily "bad" - as long as it meets specification and testing parameters.

By bringing it forward, you are actually adding to someone's workload, and in most cases they will never have to touch 90% of your poor code.

Code quality is very subjective

In most cases, in fact, you'll find that others who review your code think your good code is bad, and some of your bad code is good.

It's really, unfortunately, very subjective.

Don't give others red herrings

Don't spend your remaining time sighing wistfully about your poorer efforts there, and saddling others with worries that your code might break - they will spend hours chasing down the bugs in the wrong spots if you give them too much rope. In other words, if you give them cause to believe your code is wrong, they may skip obvious debugging steps and go right into the code when all that was wrong was a simple issue much earlier in the chain.

Complete, meaningful Documentation is far more valuable to pass along

Spend your remaining time putting meaningful comments in the more difficult to understand portions of code, putting proper headers in the files and functions, and handing off tasks that you never got to. Especially comment on design decisions, "Coded for performance, not error handling - breaks if input greater than x..."

A lot of what's lost when a person leaves are the decisions and reasoning that went into a particular implementation. When someone sees your code, they might go, "That's silly, I'm going to refactor that to follow Best Practices" only to find hours later that it was coded that way for a reason. These decisions are, ideally, in the design document, but if not put them somewhere.

If some of the code is bad or wrong, not just poorly written, then flag it

If you believe a section of code to be dangerous, or known to be broken, fix it, or pass that information along, but don't go around pointing out all the "if I had to do it over, I'd have done it differently" issues. It's a waste of time, and possibly more dangerous than helpful.

Answer 14

I'm looking at something in my editor right now and I think its the most beautiful code I've ever seen. In 3 months, I'm probably going to say "ewwwwww!" and re-factor it. I never stop learning, so I'll never stop improving. Given that, all code is going to eventually 'smell'.

So, I usually:

/* TODO:
 * This strongly resembles pasta and is beginning to
 * smell like feet.
 */

That shows whoever inherits it that I wasn't happy with it either, and I would have re-written it if I had the time. Someone else will surely understand that bosses frown on re-writing working code unless there is a really good reason to do so, code 'smelling' is often not a very good reason (to a boss).

I wouldn't worry about it. Do, however make a hand off package that offers some details. The package might be a simple e-mail that condenses your TODO's, like:

• Refactor / Rewrite libfoo, was written early on and in a hurry. Currently works, but won't scale without major surgery.

The above should be more than adequate, you're replacement will appreciate it.

Finally, don't ever get embarrassed by your old code, it documents your learning journey. Would you get embarrassed if you came across a picture that you colored / painted when you were 3?