Take the 2-minute tour ×

This question already has an answer here:

I have been working on a system alone for about four years. I have built it from the ground up. It is not a perfect system. It is very complex, it is buggy, and the business is now becoming aware of this.

After all this time, other developers at the company are getting interested in the project, and they are becoming more involved. I am a bit worried they will blame me for the problems.

Am I being paranoid? Have others experienced a similar situation? How can I soften the glare of the spotlight on my buggy code?

share|improve this question

marked as duplicate by Aaronaught, MichaelT, mattnz, Joris Timmermans, jmo21 Sep 23 '13 at 15:18


Do you believe it will be less buggy and complex if they don't look at it? –  MichaelT Sep 3 '13 at 19:41
Relax. All software that is complex enough is very buggy. Don't worry, if they will discover bugs, they will help you to solve them, too. –  Vitalij Zadneprovskij Sep 3 '13 at 19:42
No, it will be better with more sets of eyes as I have said all along. I just don't have experience moving from an individual to a team based environment. –  w0051977 Sep 3 '13 at 19:42
It is buggy, and you wrote the code, so it's your fault. That would be the case, no matter who wrote it though. It's your first code review, 4 years in the making. –  Steve Evers Sep 3 '13 at 20:30

7 Answers 7

Everybody Loves a Good Code Bash / WTF Session

I am now worried that they will find bugs and blame me for the problems.

Of course they will find bugs. You said it yourself: it's buggy (you already found bugs) and complex (it's very likely to have more).

And yes they'll blame you for it. Because it's a large codebase and they will, over time, get accustomed to the habit of tracking the problem down to your code. And it is your code after all.

However, that doesn't mean that everything you did was bad, so they may (if they are patient and kind enough) come to praise the bits you did well, or recognize value in particularly well-crafted areas of the code (assuming these exist).

Am I being paranoid

No, but you seem a bit afraid of criticism, be it fair or not.

or is there some logic in this?

As stated above, it's pretty common and normal. They'll find problems. Lots of them. You did the thing. It seems logical they'll blame you, as you are, after all, responsible for the code.

However it's not necessarily your fault for the way things HAD to be done: the company should have dedicated more resources and eyeballs to the project earlier on, and conducted more regular reviews. But from the standpoint of other developers (and damn, are we the picky and bashing kind...) it will often turn into a case of "oh great, yet another example of X's famous bad design pattern or practice".

Add lots of subjectivity into the mix (design decisions, coding style, etc...) and it's a great recipe for a perpetual code bash.

Does anyone else have a similar experience?

Pretty much anyone who's ever written code that's been maintained by someone else, or who's maintained code written by someone else. It's good to have been on both sides of the fence.

Some Advice on Preparing your Hand-Over

  • Defend your Design Decisions.

    Take the time to explain the reasoning behind your design decisions, both good and bad. You did things one way at that time, and there were reasons for it. Maybe you'd do it differently now, and maybe you already knew a different way back then, but you picked THAT way. Make sure to say WHY. If, however, you can't find a reason, then...

  • ... Don't Make Excuses.

    If something's awful because of you, say so. They'll respect you more for that. If a piece of the code sucks because you were green at the time, say so. If it sucks because you didn't know a better way at the time, say so. If it sucks because you didn't have the time, say so. We don't care why you didn't have the time. But it's good to know you couldn't do better at the time. Don't deflect blame where and when it's deserved.

  • Remember the 1st Rule of Damage Control

    Get it in the open before someone else does.

    And we do mean all of it and very early. What works for politicians, bankers and press and marketing agencies works for crap code as well (and all aspects of life).

    If your screw-ups have to come out (and here they likely will), it's best that they come out on your terms and you keep the control.

Don't Sweat It

You'll get bashed, and you'll bash other developers over the time of your career.

Just make sure to keep it light-hearted, positive, and open. It's a 2-way street, so be kind in dispatching severe but justified criticism, and be humble in accepting your share of it.

And whatever you do, steer away from holy wars.

Personal Experience

Personally, I know I've sometimes been very unkind to coworkers or said unkind things about code that had been written by people before my time. And while I hope that most of the time my criticism was at least somewhat founded, I'm sure there were times it wasn't, for various (probably bad) reasons.

We all do that crap. Don't pretend otherwise, fellow reader frowning at this. I'm on to you!

I've also been bashed a few times, and I've stood my ground when I deemed it right (or strategically worth it). But I've also accepted blame more often than not, because I fucked up. And I still do on a daily basis. Because, as mentioned, there's usually a reason for it.

As a consequence of this, it's become a tradition to hold informal code bashing sessions with co-workers. Not the bad kind (though it's been debated heartily on this site whether a "good" kind of code bash can exist). Just the kind where you kick back on a Friday afternoon and sip your coffee looking at dark areas of your codebase and highlight the best picks of the week. Then you fix them. And you don't assign blame for them. You don't even say "what a stupid way of doing X". You just chuckle at it, refactor it, review it with coworkers so your refactoring is vetted and history doesn't repeat itself, and you move on.

And you know what? Sometimes you'll even hit some shitty code somewhere and realize it was yours, and you'll humbly submit it for bashing. Because you sucked, and what's fair is fair. And you pin it to a virtual or physical wall for all to see and remember to avoid it in the future.

WTF per minute: the only good measure of code quality

For the record, at my company we have formal review meetings required by our processes, and some informal ones (way more frequent) whenever we feel we want other people to vet our stuff. And then we have informal code bashing sessions, which are more for fun. But in the end, they all have the same outcome: we improve code, and that's what matters.

As Jeff Atwood puts it in What's Wrong with The Daily WTF (emphasis his):

[The Daily WTF] is therapeutic, even educational. But whether the code in question is catastrophically stupid or just plain ill-advised, we have to do something about it. Until we do, we are implicitly perpetuating the painful, costly cycle of bad coders writing bad code, ad infinitum. And that hurts all of us.

And in general, if you approach it this way, it comes out as rather positive. You improve code, and people tend to become more forgiving. We occasionally fondly remember some out-of-this-world kind of bug, hack or plainly non-sensical piece of code, but then when a new co-worker shows up and says something like "hang on, how could someone have been so crazy/dumb as to do something like THAT?!" when they run into one of our code bash archives, we just shrug and say "hey, they probably had a good reason at the time, you know!"

And then you hope people have the same attitude after you're gone... But you won't be there to know that anyways.

Sure, a constant random number generator or an isEmpty(String) implementation duplicated across 73 different packages might seem like utter stupidity. And it is, in a perfect scenario. But, quite possibly, the guy wasn't in that perfect fairy-tale scenario. The guy had a reason at the time. Maybe not a good one, but it doesn't matter. Maybe it was just the wooshing sound of a deadline flying by.

Give him a break. I write shitty code all the time because of more reasons than I'd care to list. We all do. If your coworkers are worth 2 cents and aren't total jackasses, they'll give you the same benefit of the doubt.

Nobody Gives a Damn!

But then again... Who gives a damn?

It's your code. Own up to it. Own up to your mistakes.

Side Note: The Case for Open-Source

This is one area where open-source is said to shine. After all, in someone else's wise words:

Given enough eyeballs, all bugs are shallow.

- Eric S. Raymond's Linus Law, excerpted from The Cathedral and the Bazaar

More eyeballs during development phases means a lesser likelihood that bugs will creep up during production phases. You shouldn't be afraid of scrutiny.

You'd think the larger the crowd would imply the stricter the scrutiny. But strangely enough, in some large corporations, the level of scrutiny isn't linked to the size of the engineering workforce at all:

  • [GREAT] Companies like Google have a single code repository for most projects, so pretty much anyone can see, review and comment on anything.

  • [BAD] Others, for some good and bad reasons, compartmentalize everything and only a few number of people review code. The result is bugs and duplication.

Open-source encourages the embrace of scrutiny.

Yes, someone will be able to dig up that stupid padding error you did back in your early days that triggered a memory allocation that could be exploited to cause a pretty big fat booboo with severe consequences. So what? It's gone now, because someone found it. And nobody's to say you'd still do the mistake now. Or maybe you would, because, well, we all have days where we need coffee. Or maybe we just still suck. But it doesn't matter, there's a giant herd of people willing to try your crap code and fix it - if it's worth anything at all for them to use. You need to take that leap of faith: accept that people will be generally benevolent and you won't get scarred for life; And you won't be branded with the seal of the World's Worst Developer Ever. Quite the countrary, this will help you to improve over time. The mythical lone developer can get better, but he won't get the powerful and useful feedback received while working with a team.

If you're afraid of scrutiny, you're in the wrong game.

share|improve this answer
Awesome answer. I actually state a preference for work where other devs will be using stuff that I wrote heavily because getting that scrutiny/feedback is invaluable. Also, @w0051977 it was silly of you to be on such a large project with no input from teammates for as long as you were. Given your app development experience I'd call that management fail. If you ever find yourself in a similar situation on another project, ask for periodic code review. –  Erik Reppen Sep 4 '13 at 15:36
@ErikReppen: Thanks. I totally agree with you, it looks like there's a major management fail there. But unfortunately I'd bet the OP will still get flak for the overall failure and code quality. It's his code, and his fault for not demanding more reviews earlier as well. –  haylem Sep 4 '13 at 15:43
This is an incredibly awesome answer. Thanks for sharing! –  Simon Whitehead Sep 5 '13 at 13:17
@SimonWhitehead: Thanks. Glad you liked it. –  haylem Sep 5 '13 at 13:18
@haylem: :(. Also, this is one of the most extensive and detailed answers I've seen in a long time. There are so many positive aspects that it's difficult to pick out just one for the +1. –  Joel Sep 7 '13 at 6:07

I am now worried that they will find bugs and blame me for the problems. Am I being paranoid or is there some logic in this?

Software never complete

As it goes with an old saying - "Good software is never complete".

Every software needs to evolve and go through iterations before reaching its stable stage. Eventually the frustration builds up enough to kick off another project to cover the gaps between what the product delivers and the current business needs. By the time the project is developed, delivered, and handed off to support there are new gaps, and the cycle continues on and on.

Thus, i would not worry and just lay down current project as is, and mention that it was build on initial assumptions, and it does require improvements and fixes.

Being transparent

For a professional software developer, it is always good to be transparent with your team members, and be open for new things and suggestions. Thus, it is a way to follow for a productive team building. And transparent collaboration of skills and knowledge is a must.

enter image description here

share|improve this answer
Thanks. That is what I thought. Do you have any similar experiences? +1. –  w0051977 Sep 3 '13 at 19:48
in my previous company, i joined to the project that has a single developer on it. He told me about bugs, and we prioritize them, and go through them by fixing/improving the code –  Yusubov Sep 3 '13 at 19:50
the finger-pointing of application bugs/issues to the original developer is a waste of time, and not a professional behavior. it is productive to understand the context of problem, and solve it asap. –  Yusubov Sep 3 '13 at 20:19

I hope you're not to blame. The company couldn't put the resources needed to make a large and complex application as robust as possible, so they had a jr. dev to it. Maybe the app wasn't expected to be so critical at the time. The fact they want to continue the project probably shows you did something right. Now you can get some help, learn a few things, and refactor a lot of code. Nothing new in this business.

I wish I owned a software company and some middle manager tried to blame an entry programmer on the problems with such a project. "We let him code for 5 years with no help, support or code review, but I thought he was a better programmer." Could I possibly fire the manager fast enough? This is someone who is pretending to be a manager and completly abdicated his/her responsibility to this project.

share|improve this answer
Thanks. I don't understand your first sentence: "I hope you're not to blame". Plus even thought it is my first "developer" job I wouldn't call myself junior as I was in app support for 7 years previous. I don't suppose this has any bearing. +1. –  w0051977 Sep 3 '13 at 20:23
@w0051977 - I JeffO means that he hopes the company doesn't blame you. I certainly agree with him - Blaming you for not doing the work of a whole team would be stupid on their part. –  Bobson Sep 3 '13 at 21:12
@w0051977 - Bobson is correct. I guess if you were in a support role that involved writing code, you may not have been a junior when you started, but the fact this is your first app should put things into a different perspective. –  JeffO Sep 3 '13 at 23:02

Keep the Atmosphere Positive

Make sure that all the programmers expect to find bugs. Make sure they get praised for resolving problems. Express thanks that you're getting the help you've needed to move on to other interesting problems.

Avoid Being Defensive

Don't say you're sorry. Don't be upset. If there are challenges suggest improved processes to solve them. Maybe you need new testing procedures? Maybe you need better requirements?

share|improve this answer
I find the best way to keep an open mind is to write down the other person's thoughts and then think about the usefulness later –  TruthOf42 Sep 3 '13 at 21:00

Its Not your Code. It is the companies Code.

They are the ones who allowed you to go 4 years without serious outside inspection of the code, they should bear responsibility. (That said, you wrote it so some of the shit will stick).

I would take this as an opportunity to embark on a really great (if painful) learning experience. If you can be harder on your code than your reviewers, then you will be seen as a positive driver of this phase, rather than a negative, defensive factor.

share|improve this answer
+1 for mentioning how to be a driver –  Marcel Sep 4 '13 at 9:32
It's generally the more experienced devs that are the first to admit they didn't like something they wrote. It's the least competent managers that look at you like you're crazy when you do that. –  Erik Reppen Sep 4 '13 at 15:40

I'm in the very same situation as you are. The place I'm at is where I've been for the last 5 years, and I've spent 80% of my time building a system for internal use from scratch - on my own.

This is my first job, meaning that it is the first job I got after i graduated. I, just as you, know that if I were to begin work on the very same system today I would to things differently. However, that's the beauty of experience. As long as you are able to identify the mistakes you've done, it's a good sign. It means that you've learnt something.

As for the things you have not identified yourself, but which the others probably will : embrace the feedback you get and learn from it. Don't be afraid of the feedback you get. You did things for a reason when you built it, and as long as you explain why things were made a certain way, then there's ground for a good discussion. After all, you're all grown ups so I assume you will talk about it the way grown ups do. As for the question of "blame"; you're the one who built the system so it's pointless to even talk about that. You all know that it's your "fault". The focus should be on how to improve it, and you will get a great learning opportunity for free.

I'd love if someone else would take a look at the system I've built. I, just as you, work alone and if there is something I miss it's being able to discuss my work with a colleague. I'd say you should value the opportunity :-)

share|improve this answer
Letting someone fresh out of school build an application from the ground up sounds like terrible guidance to me. I hope people at least pointed you to frameworks, CMSes and open source packages. –  winkbrace Sep 7 '13 at 18:41

As others said, this is the perfect opportunity to learn and improve the project.

Additionally, I would also try to document the current state from a high architectural standpoint, if that is not already done. I am not talking about class diagrams here, but more the kind of package or component diagrams or probably some very coarse (data) flow charts.

This will help your new fellows to grasp an overview of the project in a short time and will quite automatically show the spots you probably want to to some cleanup work first.

share|improve this answer
