(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.

I’ve read a number of books about Test-Driven Development. There are a number of new ones, but most of them start with a clean slate where you’re writing code from scratch.

Working Effectively with Legacy Code is different. It starts with the assumption that you already have a codebase that doesn’t have tests and need to figure out how to start adding tests as you work on the existing codebase.

The book is organized into two sections. “The Mechanics of Change” are an introduction to TDD, tools, why you would want to do it, etc. The real meat of the book is the second section, “Changing Software”. Each chapter in this section addresses a different question, such as:

• I can’t get this class into a test harness


• This class is too big and I don’t want it to get any bigger


• We feel overwhelmed. It isn’t going to get any better

And each chapter has a detailed discussion of the problem, the strategy or strategies you might use, and the tradeoffs involved. That last point is pretty important – the Agile community has more than its share of zealots, so there’s a lot of dogmatic advice out there. This book is the opposite – the author has clearly spent a ton of time applying his techniques to real codebases, and there are lots of interesting discussions out there. Even if you aren’t sold on the whole Test-Driven approach, there’s a lot of content that will apply to general refactoring.

This is one of the best books I’ve read in the last few years. Highly recommended.

The year was 1979. Or maybe it was 1980. I’d been programming for a couple of years, but didn’t have my own computer. *Nobody* had their own computer. But I did have enough for a magazine subscription.

There were only a few serious choices. BYTE was one choice, but it was – even in those years – not terribly exciting. Another option would have been Dr Dobbs (Full Name – “Dr Dobbs Journal of Computer Calisthenics and Orthodontia“), if I’d know that it existed.

The third option was a publication known as “Creative Computing”. IIRC, I forked out the princely sum of $15.98 for a two year subscription, and never regretted it. Creative had a unique mix of information, entertainment, and irreverence. I kept a few articles over the years, but the majority were tossed out.

Today I came across an archive of computer books of the late 70’s and early 80’s at AtariArchives.org, and among those are 3 “Best of” volumes from Creative Computing.

If you’ve been waiting for a good ASCII art version of Snoopy and Charlie Brown, you can find one. Or, if you need a review of Wumpus 2, you’re in luck.  

Now, help grandad back to his rocking chair, will you?

More sage words from Rico…

And a followon…

You need to design the outside of a fish. What is the first thing you do?

You build a scale model.