Category Archives: Software Development

Code Complete 2

I finally bought myself a copy of Steve McConnell’s Code Complete, 2nd Edition. I’ve read about a third of it so far and love it. It’s by far the most practical and useful book on programming I have ever read.

But how to learn it all? Sure, an experience programmer will pick up many of these ideas over time, but how can I start implementing ALL of them?

I think my plan is to read it through once, and then while I sit at my desk at work (or home), leave it open to a random page so I can think about the displayed topic.

A Month with NUnit

I’d been hearing about this thing called NUnit for the past 6 months, and finally two months or so ago I decided to see what all the hoopla is about.

NUnit is a .Net version of the original JUnit unit-testing package for Java. The newest version has a very strong .Net feel with its use of attributes to control testing.

I decided to start using NUnit in my BRayTracer project. Immediately, I was faced with some issues (not problems, just things I needed to decide).

The first is that NUnit works by creating classes that contain methods which have the TestAttribute applied to them. This allows NUnit to find all of the testing code given a module or project.

I could either put this testing code into the same module as the existing code, or I could break my ray tracing code into a separate module. I didn’t want the testing code to bulk up my executable size (which can in some instances translate to slower code due to paging and locality issues). I decided to break my ray tracing code out into a separate module (I was planning on doing this eventually anyway).

Done with the housekeeping, I began setting up my tests.

So far, I’ve implemented about 150 unit tests covering a few my objects. It’s not totally comprehensive yet, but it’s a good start. Effectively testing the entire rendering process will require thousands of tests.

So far, the tests have helped me fix about 10 serious bugs that I had otherwise missed. The regressions testing is helping a lot, since the code is still in a lot of flux.

I’ve been making a strong effort to write all (most) the tests before I write the code they’re supposed to verify. This definitely makes testing more enjoyable, and more likely to get done.

I’ve been thinking about how to use inheritance and polymorphism to my advantage in these unit tests. I have a Shape object and numerous subclasses (Box, Sphere, etc.). I initially had a few abstract functions in Shape to test basic functionality of all shapes, but I found that this isn’t really buying me
much. So much code has to be taylored to the individual classes that inheritance is helping in that way. More analysis will be needed.

Another aspect of using NUnit is that I’m finding myself needing the debugger less and less. It’s now possible to narrow down problems very quickly with such focused tests. This translates to quicker development.

So far, so good… I’m converted.

Example of a Great User Interface

Designing good user interfaces is a very hard thing to do. It’s something that Apple does great, Windows does generally pretty well, and Linux is getting better, but…

Instead, I have an example from the more mundane world of consumer electronics.

Many years ago, I bought a certain alarm clock from Sony. (I’m sorry I don’t have a picture–I no longer have the radio, and haven’t been able to find a picture on the web) It lasted many years before finally dying earlier this ear. I was pretty sad about it, but I didn’t realize how wonderful it actually was
until I got a replacement.

To summarize the features, it had a digital AM/FM tuner (absolute requirement for me–I can’t stand fiddling with tuning knobs), two alarms, a sleep timer, an LCD panel, and…well, that’s about it. It was flat, black, and pretty small.

The buttons were all arranged on the top part of the radio in three rows. There was a “top” row located towards the back, a middle row, and a “bottom” row closer to the face, which was angled, not vertical.

If I were to do a little descriptive diagram of the button layout, it would look like this:

(On) (Off)(Tune Down) (Tune Up)

(1) (2) (3) (4) (5)

The particular genius of this device is that it is exceedingly simple to use in the dark, when you can’t see any of the buttons but have to go on feel alone. It’s genius because It’s HARD to design simple things.

  • The functionality is dvided into three rows: it’s easy for the fingers to find where they are among three options. Plus there are other guides as we’ll see below.
  • The On button has a “normal” convex surface, but the Off button has a concave surface. This makes it very easy to figure out which button is which, in addition to left-right difference. Your fingers adapt and “learn” which button does what by feel better than position. (The On button also doubles as the sleep timer, when the radio is already on)
  • The Tune Up/Down buttons have little < and > grooves on them. It’s hard to tell which groove goes in which direction so in this case you have to memorize the location. Since there are only two buttons, this is relatively easy to do.
  • The row of five preset buttons has a very simple mechanism to orient your fingers: button 3 has a little raised dot on it. This instantly allows you to figure out where the middle is, and move to the correct preset. (Buttons 1 and 2 also set the alarms when the alarm is off).
  • The buttons were about the size of my fingertips. Any smaller and they would be harder to press; larger and they would be too far apart.
  • The arrangement of the buttons in three rows gives a compact layout that easily allows the fingers to travel to other buttons quickly.

Most of these things I just took for granted–until it died. My new alarm clock works pretty well, but it’s MUCH harder to use at night. There is just a single row of about 6 (small!) buttons for things like sleep timers, tuning, changing the band, etc. Some of the functionality is divided into other areas, but overall, it’s a much less effective design.

There are a number of lessons to be taken from this experience that can be applied to software as well:

  • Layout often isn’t enough for an effective interface. Just as an alarm clock usability increases with subtle, but smart, tactile cues, an application’s interface benefits from smart visual cues. I’ll cover what some visual cues can be in a future entry.
  • You need to consider use cases when designing an interface. Given the design of some alarm clocks, I wonder if the engineers ever took them home to test them. Same with software; you need to consider and test how users interact with the interface. What makes sense to the designer might be completely unrealistic to the average user.
  • Design can be a very subtle problem. How did they know to put a raised dot in the middle of the preset buttons? How do you first realize that it greatly increases usability?
  • You need to think about the usability of each component in an interface. Even the “simple and stupid” items like buttons and labels. If you’re making your product accessible, there are even more things to worry about.