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.

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.

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.

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.

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?

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.

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 🙂

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.