Fairy tales always start with “Once upon a time”, and programmers tales starts with “when I was at a client”…

Two days ago I was a client, and the discussion turned to bad code bases, as it often does. One story that I had hard time understanding was the Super If.

Basically, it looked like this:

I had a hard time accepting that someone could write an if condition that long. I kept assuming that they meant that the if statements were 50 lines long, but that wasn’t the case.

And then yesterday I had an even more horrifying story. A WCF service making a call to the database always timed out on the first request, but worked afterward. What would be your first suspicion? Mine was that it took time to establish the database connection, and that after the first call the connection resided in the connection pool.

They laughed at my naivety, for it wasn’t connecting to the database that caused the timeout, it was JITting the method that the WCF service ended up calling.

Yep, you got that right, JITting a single method (because the runtime only JIT a single method at a time). I had even harder time believing that, until they explained to me how that method was built:

Some interesting stats:

It had a Cyclomatic Complexity of either 4,000 or 8,000, the client couldn’t remember.

The entire Rhino Mocks codebase fits in 13,000 LOC, so this single method could contain it several times over.

But you know what the really scary part is?

I upgraded from Super If to Black Hole Methods, and I am afraid to see what happen today, because if I get something that top the Black Hole Method, I may have to hand back my keyboard and go raise olives.

Ha, "It had a Cyclomatic Complexity of either 4,000 or 8,000, the client couldn’t remember." :)

How many defects (not even related to JIT optimizations) such method contains than?

And it's only one method... What about whole application??? ;-)

So few things raised in my hand:

a) The client does not even hear about cyclomatic complexity, not just "couldn't remember how much it was" :D

b) I think your fix will have "short life-cycle" and probably you waste time trying to help, because such a code written in .NET simply can't work :) :D :D :D OK, maybe it can, if they will substitute existed JIT compiler with own implementation with black holes support and optimizations :)

But if say frankly, we all from time to time dial with such "legacy" code (or better to say "legacy coding style from native C++) and instead of completely rewrite it, try to "fix" it, fix it and fix it... sometimes it's do work actually ;-)

A 75,500+ line method must require a ridiculous level of patience to write assuming that it's not some generated code that is simply cut and pasted in.

Someone with that much patience surely would think at some point "maybe I should break this bad-boy down a bit". I've seen plenty of 1000 line methods in my days, but when you start approaching War and Peace size proportions, even the most stubborn programmer would start re-thinking their design, right?

Reminds me of similar code I encountered in a legacy product created by the Consulting Services branch of a world-known multinational company (for its arrogance as well as its software), including this pearl
http://bit.ly/aBsckf

Anyway, you should consider almonds. They have a higher ROI than olives, but you have to pick them in the summer :P

There is an entire industry full of terrible programmers who make a living writing custom apps despite having no idea what they are doing.

I used to work on the compiler engine for REALbasic, and we would periodically get bug reports complaining about ludicrously bad compiler performance. At first I had trouble believing them - our largest test projects compiled in maybe 4-5 minutes, tops, so it was hard to imagine how anyone could be waiting 45 minutes to an hour for a compile.

Then we started getting bug reports with actual code attached, and some of the examples we saw were every bit as bad as the examples quoted above. Eventually we learned to stop saying "no real program would ever do this"; every time we would be proven wrong by the ingenious, determined perversity some of our customers used in place of clue.

Seriously: single methods with 40k-50k lines of code. Conditional blocks nested over a hundred levels deep. Tens of thousands of local variables in a method. Single expressions, stacked up over line after line, containing thousands of sub-expressions, all executed as one statement. Classes with thousands of methods and hundreds of thousands of line of source code. Classes with thousands of methods, each containing a single statement. Inheritance hierarchies a hundred classes deep.

"I upgraded from Super If to Black Hole Methods, and I am afraid to see what happen today, because if I get something that top the Black Hole Method, I may have to hand back my keyboard and go raise olives."

What? I've read this a dozen times, ignoring the grammatical errors, and I'm still not sure what you are trying to say.

That's a rather simplistic view, isn't it? Maybe Griff has a wife and kids so just up and quiting isn't an option, maybe he's in a situation where he has medical problems and if he leaves his current place of employment that he will no longer get medical coverage (very common here in the US), or maybe it's just one aspect of his job he doesn't like, but the rest of it he's okay with so it's a necessary evil.

Or it could be none of the above, but "either change it or leave" rarely is feasible in real life.

I've beaten this horse to death with Ayende via private emails already, but the biggest impediment of "being change" within a Microsoft shop is Microsoft itself. Obviously the mothership isn't saying "build a 76000 line method", but they also don't promote good code quality either (look no further than crap like Oxite or their broken code on MSDN for examples).

This is a complex world, full of complex problems, and "lead or leave" is rarely the right solution.

I worked at a place that was constantly battling a SQL 6.5 limit on triggers at 8K characters per table (as I remember). Many of their triggers had already been "optimized" to turn each variable to use 1 character names and other minification techniques.

Due to timing issues on the triggers, it was impossible to tell what would happen when a row was inserted into the OrderDetails table, which was a problem because that was the integration point between all of their order systems.

The reason they were stuck on SQL 6.5 compatibility was that they had many Powerbuilder applications that couldn't work with newer versions of SQL Server.

That was the only job I've stayed at for less than a year. I tried to stick it out for a full year, but I just couldn't do it.