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
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
... 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
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
And whatever you do, steer away from holy wars.
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.
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
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
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
[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.