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:

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

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…)

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

Practical Tips For Boosting The Performance Of Windows Forms Apps

Raymond writes an interesting post about how some programs run faster if you hold down the mouse.

This is a classic situation to get yourself into – I’ve probably seen it 5 times, and hit it again recently.

When we’re burning a DVD, the burn engine calls back into the UI layer so that we can update the progress bar. To give the user a single monotonically-increasing progress bar, we (well, Dean, actually) have to play some games with our progress tracking, which means that sometimes we get progress callbacks once a second, and sometimes we get them 100 times a second.

The progress dialog looks fine, but if you look a profile of the burn, you’ll find that a fair amount of time is being spent in the UI code updating. In this case, it’s not a big deal, but I’ve seen cases where programs are spending 90% of their time updating the UI. That takes a 10 second operation and makes it take 100 seconds, which is pretty bad.

The fix? Well, there are two good ones.

The simplest one is to simply update every <N> calls. I traditionally start with N=10, which is guaranteed to same 90% of the overhead, and usually works fine.

If your callbacks are sporadic – as they are in the DVD Maker case – it works better to timebox the updates. Whenever you update the UI, record the time, and then don’t update it again until a specific time has gone by. I usually find 1/4 second to work well.

Paul wrote an informative response to my post on collaboration.

I’ve just been writing some stuff about where I think our group should go in the future, and I’ve decided to downplay pair programming. Not because I think it’s a bad idea, but more because I think that opinions around it tend to be a bit religious.

Instead, I’ve decided to advocate an open environment where pairing can happen in a natural way

There have been some interesting discussion on our internal “agile” alias around pair programming, with some advocates and some skeptics.

I wrote something in response to one of the skeptical posters, who (to paraphrase badly and perhaps miss his point) said that he was an introvert and preferred to work alone. Not that I’m advocating forcing something like pair programming on anybody.

Here’s what I wrote, slightly edited to protect the innocent.

*****

1. It’s the right thing to do

1. You’re an introvert. Given the choice between personal interaction and working on something new, you usually choose something new.
2. Your co-worker is also an introvert.
3. Nobody really understands your code because you’re the only one who works on it, so the review may not give useful feedback
4. You have to get up, leave your office, find the person, and bring them back. Lots of time, and they may not be there.
5. You get evaluated on the features you produce and don’t feel review pain because of the bugs in your code.
6. It’s early/late, and you’re by yourself
7. You don’t want people to say bad things about your code.

I’ve been talking about some agile techniques with one of my co-workers, and one of his concerns about pair programming or not being in separate offices is that he won’t be able to get into a state of flow in that kind of environment.

My limited experience with working on projects in group settings leads me to believe that the benefit you get from informal collaboration is far more important, but I’d like some more data.

What do you think? Is the lack of time for flow a real issue, and if it is, how do you deal with it? Or do you find that the collaboration is more important.

Tonight I read a post by Eldon, where (among other things) he says that he has learned how to lose himself in his ride. I’ve experienced that a number of times – I’m just riding, still paying attention to what’s going on, but not thinking about anything.

I’ve been thinking about how that relates to the flow state when programming. In my experience, it’s a lot easier to get into the flow state when programming than it is to get into the analogous state when riding. It may have to do with the degree to which you can shut out external input. In programming, it’s pretty easy – put on some appropriate music, and lose myself in the task. On the bike, it’s often not possible, since losing oneself can have some pretty bad consequences.

Thoughts? Are the two states analogous, or are they different things entirely?

• General comments and suggestions
• New climbs to add, both on the eastside and in Seattle and elsewhere
• Better data for maximum gradients
• Descriptions for the climbs.
• Rankings for the climbs. I currently have green, yellow, and red. I’m going to add something beyond red for climbs like the zoo, but if you think I’m off on the relative ranking of climbs, let me know.

More sage words from Rico…

And a followon…