Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,124 | Comments: 45,479

filter by tags archive

My Code Sucks

time to read 3 min | 478 words

There is a point where a project goes beyond the pale, where the complexity goes so far out of line that it is simply ludicrous.

I had such a point today. I had enough with SSIS and decided that I want to replace it with something better. I wrote an ETL tool to handle that in a few hours.

Why is this relevant? Because I have already build an ETL tool. Rhino ETL.

It is quite telling when the author of a tool decide that he doesn't want to use it.

I was decidedly proud of Rhino ETL for a while, then the problems started to creep in. The problems were not in the code per se, the entire architecture of the code was overly complex. In order to handle this complexity, I had resorted to throwing code at the problem, and then more code, and more code yet again.

At the moment, the current code base has two "minor" problems, exception handling and threading. The bigger problem is that I don't want to have to wade into this stinking pile and try to figure out what is going on there. I tried to be clever, and it is clever, in a horrible sort of way.

I don't have the time or patience to decipher code at the best of time, and at this point, it has gotten simply too complex. The project right now is at ~9,000 lines of code, so it is not that it is big, it is simply complex.

From the architecture perspective, I have made one huge mistake, I exposed the threading model to the application code. You can say that this stand in the root of my problems. I actually re-wrote this once already, moving from a home grown threading solution to using Retlang for threading. I made the same mistake and exposed the threading model to the application itself. Can you say: Big mistake!

From the point of view of the project itself, I started by defining the DSL syntax, and then built the project around that. It turns out that this has the usual "let us build the whole layer at a time". It also meant that a lot of the code had deep assumptions about the way it is called, making it unusable for using in other ways. This is excusable if we are talking about the DSL mapping layer, but not for the core code base itself.

Anyway, I am ranting and I should stop.

I spend six to eight hours today rewriting it from scratch.  It doesn't do threading, and it doesn't have a DSL interface yet, but it does pretty much everything that the old project did, in a quarter of the lines of code, and in a way that is much safer and easier to handle than what we are using currently.


Mats Helander

"My Code Sucks"

I beg to differ. But:

"Anyway, I am ranting and I should stop."

No, please go on! This was a really good post imho...the "It turns out that this has the usual "let us build the whole layer at a time" " remark was priceless, as was "I tried to be clever, and it is clever, in a horrible sort of way.".

Very few posts are as informative and interesting as when a good coder rips some code to shreds, critisizing exactly what's wrong with it - but doing it to someone else's code isn't really polite so the only reasonable option is to attack your own code. But that takes Big Kahunas to do publicly like this. Kudos.



I agree with Mats.

Maybe it's the short week for me at work this week, but today I opened some code I was doing before Christmas. I know I was liking it before Christmas, but I saw it today and thought: wow, you really complicated this thing Steve.

I went back, refactored it, removed some of the extraneous complexities and made it more simple.

KISS is a principle I like, and when I try to get too 'fancy' I end up scratching my head later saying 'gee, did it need to be that hard' :)

Just glad to see you share this info though, its insightful

Jeremy Ross

This is great because this is the same kind of stuff that almost every project faces. Sometimes you have to stop and "clean up the kitchen". Boundaries start to get blurred, the orthagonality of layers and abstractions become compromised.

You're doing the right thing. Martin Fowler says that you can NEVER do it right the first time. Always makes me feel good to hear someone like Mr. Fowler say these kinds of things.


Joe Ocampo

I don't know what is more impressive...your humility or the fact that you rewrote the dam thing in less then a day!

Jeremy Gray

Keep it comin'! Everyone's code progressively sucks, a little more with each character they type. :) And it keeps on sucking until you go back and clean it up (which in turn gains its own, but hopefully smaller, suckitude.) There's nothing wrong with this: it's just how we all learn and learn all the time, we do.

Darius Damalakas

You know what I like most in my team?

When people do criticize their own code. Not wheeping, not crying "ah, i am stupid" (yes, maybe you are), but giving strong concrete and personal opinion of why the code is bad.

This is what i do constantly in my team - i publicly criticize my own code and then tell how i would do it better. And i encourage others to do so too.

Jon Skeet

Darius: Agreed. There's another attitude I really like - encouraging others to review hard.

In a previous job, I had a colleague who would always come to me for a code review, even though she knew I'd be more likely to really look at the code and suggest changes than other reviewers might. (Many people did really cursory reviews.) She knew that it would almost always mean more work for her, but that she'd improve because of it. I can't think of many better indicators of someone's commitment to quality and self-improvement.


The second time you write something it mysteriously goes better :)


I agree about the dangers of starting with the DSL. I think the same danger applies if starting with the config interface. It's better to start with the "raw" imperative object model and then layer the config or DSL on top of it, sort of like writing the business logic with no UI dependencies and being able to layer a "wizard" UI on top of it (fluent interface), a "power user" UI, and so on.


Your mind is brilliant - don't be too hard on yourself.

Keep things Mozart simple. People are more impressed with simple anyway. Besides, simple is easier to debug so you can get on to other pressing issues.

I stop by daily to read you - even if I don't always understand the triple back-flip stuff.


I'm going through the same sort of thing as well. Like others said version one never really works. In my project we never really had any specs to code from (basically a productionized prototype), but in reality that is just a lame excuse on my part.

I think in the end a programmer a while back worded it best, programming has a lot of peaks and valleys. I see that in my own code quite often, one day things are great and the next I am asking myself what was I thinking.

Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - one day from now
  2. The design of RavenDB 4.0: Physically segregating collections - about one day from now
  3. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 3 days from now
  4. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 6 days from now
  5. The design of RavenDB 4.0: Voron has a one track mind - 7 days from now

And 12 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    02 May 2016 - You want all the data, you can’t handle all the data
  2. The design of RavenDB 4.0 (13):
    03 May 2016 - Making Lucene reliable
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats