Things I didn’t learn pt.8

Running on empty.

I just don’t seem to learn, do I?

Artificial Intelligence

lispmachineYears ago, I wrote my Master’s thesis at the university’s Artificial Intelligence lab. I extended an expert system to make it learn from experience.

The software ran on Lisp Machines. We only had three of these machines on campus, two in the lab where I worked, another one in a lab on the other side of campus. Lots of people wanted to work on these machines. The machines were clearly a bottleneck.

There was an “interesting” way to deal with the bottleneck: the staff could use them in the day, students could use them in the evenings.

Natural stupidity

I came in each evening to work a bit on the application. Load the application, which took a while. Check the changes that the TA developing the expert system, had made during the day. And then I could work on the part of the application I had planned to work on.

Each evening the same scenario would repeat itself: I made a bit of progress and then got bogged down with a problem. No matter what I tried, I couldn’t solve the problem. I was stuck. Tarpitted. I went home.

Next morning, I looked at the previous evening’s problem. The problem that seemed so difficult the night before, was actually very simple. You had to be really stupid to not be able to solve that problem!

I finally managed to implement the system after struggling for many nights. It wasn’t a particularly great piece of software.

Stop wasting my time with time management courses

A few years later, my company sent me and my team on a three day off-site “Time management course”. That would teach us to use our work day more efficiently, they hoped. Unfortunately, the company also asked me to perform an important technology assessment that same week.

So, I had to come to the office each evening after attending the course, to finish that assessment. This useless time management course forced me to do overtime that week! Stupid course, it didn’t teach me anything!

Go home!

Years later, I managed a team. Extreme Programming was all the rage then. It all sounded very plausible. I was determined to apply the “Sustainable Pace” (then called “40 Hour week”) practice. Each evening I would do the rounds of the office to see if people were working late.

When someone worked lated, I gently reminded them to leave on time. If they were still working late the next day, I sent them home. If they still worked late the next day, I told them to see me the next day, so that we could discuss what problems they had. This allowed me to discover and fix several problems early. Code quality improved.

As usual, I had made the rule and I thought it didn’t apply to me. I still worked long hours. I got stupider by the day. Unfortunately, there was noone to tell me to go home. I had sent them all home.

And what have we learned from this?

We don’t do stupid things like that anymore, us Extreme Programming experts, do we? At the previous Pair Programming Party we tried to implement a very simple story. We were all a bit tired after a full working day, but it was such a simple feature.

Following the TDD canon, we wrote a failing unit test (several lines of code), implemented the code to make the test work (half a line of code) and expected the unit test to succeed. It failed. Whatever we tried, we couldn’t get this code and its test to work the way we wanted to. We finally gave up.

Two days later, I looked at the code and the error jumped me in the face. You had to be really stupid to not be able to solve that problem! … That’s how it’s supposed to be, isn’t it?

Lesson learned:

  • Four (pairprogramming) eyes see more than two
  • Four tired eyes are just as blind as two tired eyes.

Well, at least the expert system learned from experience…

Tags: agile