Worst… Code… Ever…

March 16, 2006 at 12:24 pm

Like many developers, we enjoy making fun of other people’s code. I’ve had lots of those discussions over the years. And when it comes to who has had to work with the worst code, I’ve never lost.

Way back when I was just out of college – when 7-bit ASCII ruled the world, and people hadn’t decided whether lowercase characters were a fad or not – I worked for a Large Seattle Aerospace Company, at Large Seattle Aerospace Company Computer Services, in a group that built graphics tools for engineers.

One of the libraries that we owned was generated code.

Now, I don’t hate generated code. The Windows Forms Designer and I have a generally felicitious relationship. I even have a patent cube (which you get when an application is accepted at Microsoft) sitting on my windowsill that is related to an architecture for doing generated code.

This particular library was special. It goes without saying that the source to the generator was lost in the card recycling bin of time, but that was not what made it unique.

First of all, it was in FORTRAN. And not that namby-pamby FORTRAN where you can have modern control structures, this was FORTRAN 77, and you had better know how to count spaces and what it meant to put a character in column 6. Did you think that python came up with the idea of significant whitespace? Pshaw.

Secondly, the programmer who had written the code generator was a bit of a FORTRAN afficianado. There’s a feature in FORTRAN 77 known as the “assigned goto”. Here’s an example:

      NUM = 40
      NUM = 50                ! This statement is not executed
30    ASSIGN 1000 TO IFMT
      PRINT IFMT, NUM         ! IFMT is the format specifier
1000  FORMAT(1X,I4)

Now, to understand this, you have to remember that by default, any variable that starts with the letters I-N is implicitly an INTEGER variable (all others are implicitly REAL). So, you can assign 30 to LABEL (this is *not* the same thing as writing LABEL=30, which means what you expect it to mean), and then use “GO TO LABEL” to goto 30.

Suffice it to say that the developer had never read Dijkstra.

Now, my guess is that while the vast majority of you are thankful that you don’t have to work in FORTRAN, there is a divide in opinion beyond that. Some of you are saying “Well, that’s not really that bad”. But the rest of you are shaking your heads, because you know what is coming.

When you’re doing code generation, you need to somehow come up with variable names. In this case, the developer took the easy way out, and all integer variables were something like “I1344”.

And line numbers also use the same range, starting at 1000 and going on up.

So, it means that the code has lots statements like:

GO TO 11634

and lots statements like:

GO TO I1655

Did I mention that in the fonts of the day, the difference between “1” and “I” was fairly subtle? Even if you did notice the I in front, you had to cope with the fact that

GO TO I1655

really meant

GO TO 3455

At least, it meant that sometimes, but I1655 would be re-assigned when the program ran.

IIRC, there were about 15K lines of this in library.

So, bother me not with tales of poorly-formatted C# code or 2000 line C functions. They are mere trifles. To snatch the rock from my palm will require something stronger. Are you up to the challenge?

(I am a bit worried that there might be some LISP or APL programmers out there…)

The capability immaturity model

March 15, 2006 at 11:59 am

I was reading the DailyWTF this morning – a great read, BTW – and came across a link to the Capability Im-Maturity Model, which I thought you might enjoy.

TDD and design methodologies

March 7, 2006 at 1:24 pm

(something I posted on our internal agile alias, in response to a question about how design works in TDD…)

There’s an underlying assumption in software engineering that “more design == better design”, despite that fact that the vast majority of us have worked with baroque systems that answer a bunch of questions that nobody ever asked.


The traditional theory is that if you don’t do the up front design, your code will be poorly architected, inflexible, and you’ll be in trouble when you try to maintain it. Which is true. But it’s also true that up-front design – especially the “spend a milestone” type of up-front design – often leads to the same result.


The ideal architecture is a minimalist one. It provides all the features that are needed and no features that aren’t needed (I mean “features” in the class method sense, not the user-visible sense)


The up-front approach attempts to do that without the data around which features are needed and which ones aren’t needed, which always changes along the way.


TDD says, “We’re going to figure out what we need and how to put it together along the way. We know we’re not going to get it exactly right the first time, but with our tests we can refactor as necessary



Practical Tips For Boosting The Performance Of Windows Forms Apps

March 7, 2006 at 12:18 pm

Practical Tips For Boosting The Performance Of Windows Forms Apps