Monthly Archives: March 2008

Makefiles. Why Projects Fail. Process. Etc.

It feels like spring today.

This year is turning out to be like the last. There are still no flowers, although the bulbs we planted last autumn are pushing through the ground. The leaves will likely come late, too, despite budding after a 70 degree day in January.

Even though it might snow tonight, I’ve come out of my den to look around and survey a winter’s worth of earnest work. Here are some random thoughts mostly in a software engineering vein that I’ve had over the long, cold winter. (If you’re looking for something related to human vision, consider V1, a site about “the primary visual cortex.” If you come here for photography, stay tuned.)

Makefiles are what UNIX-based programmers (and ambitious Windows programmers) use to build software, manage dependencies, and create a common set of compilation parameters. Working with makefiles is hard, and I think that most of the difficulty comes down to the difference between imperative versus declarative languages.

In the real nonacademic world more than 99% of software developers develop applications in imperative languages, where you tell the system how you want it to do things. Makefiles take a radically different approach. As a declarative language, you tell what you want the result to be and then leave it up to the make application to figure out how to do it. It takes a bit of brain rewiring to shift from working with code where you can trace what’s happening to code where you look at the inputs, the desired outputs and the parameters. It’s a shift from knowing what individual commands do to knowing how the whole system works behind the scenes.

Construx Software, Steve McConnell’s software best practices company, published a white paper on classic software engineering project mistakes a couple months ago. I participated in the survey and was interested in seeing the results. Here are the biggest mistakes according to risk exposure:

  1. Unrealistic expectations [2]
  2. Overly optimistic schedules [1]
  3. Short-changed quality assurance [4]
  4. Wishful thinking [7]
  5. Confusing estimates with targets [9]
  6. Excessive multi-tasking [3]
  7. Feature creep [6]
  8. Noisy, crowded offices [5]
  9. Abandoning planning under pressure [11]
  10. Insufficient risk management [8]

The numbers in square brackets are the ranks of how often the mistakes happen in projects.

Jeff Atwood posted a very interesting article about software process. He doesn’t come right out and say “Process! Bah, who needs it?” But he does invite a contrast between what professional software organizations need when they aim for process compliance and the open source projects that frequently shun repeatable processes. He also highlights the trade-off between process management and delivering features. The comments provide interesting food for thought for people seeking to optimize their process and/or deliver new features.

This is the final week of the spring semester. Shortly I’ll be 7/10 done with my software engineering program. This is my first semester without any theory classes, which is why I’ve had to go to the web for the deep insights. Instead, this semester I’ve been learning about the mysteries of UNIX programming: users, filesystems, processes, pipes, etc.

If all goes according to plan, my last three courses will be all C++ all the time, with an object-oriented design course thrown in for good measure. It’s nice how all of my courses have dove-tailed with what I’m doing at work. I’m going in a new direction at work, and I think this pattern of learning things I can use right away will continue. . . .

Posted in Life Lessons, Software Engineering, Worthy Feeds | 3 Comments

My Spring of 100 Mistakes

A while back, I bought myself a new camera. Then about a month later, I figured out how to attach the lens to the lensboard. So, for a while I had a camera without a lens. Things were improving after adding the lens, but I still had no idea how to put film into it. Obviously it involved the “film holders” I bought. Clearly, I had a lot to learn.

Today, I embarked on my “Spring of 100 Mistakes” as I teach myself the practical techniques related to large format photography. We’ll see if I actually make it to 100 mistakes, or perhaps I’ll blow right past. My goal is to have a pretty solid intuition for how to operate my camera before taking it on our month-long summer trip through the American Rockies.

(Short side-story: I first started photographing in the summer of 1990 when we moved to Wyoming. On part of the six-hour drive from Casper to Yellowstone, I read the whole manual for the family’s mostly abandoned Sears KSX-P camera. By the time I got there, I was shooting Kodachrome slides without fear, just like everybody else. That was a great little camera with a Pentax K-series mount. I’ve been telling myself that I should sell it; I haven’t used it since buying my two Nikon rigs a couple years after graduating college, but there’s still a soft, squishy place in me for the camera. Anyway, I like the historical echo of going back to Yellowstone with a new camera and working without a net again.)

So here are the first few mistakes:

One: When loading film in complete darkness — a nonnegotiable requirement — know how to determine which side has the emulsion. The film is right side up when the notched corner is the upper-right-hand one.

The right way (Click for larger)

The wrong way (Click for larger)

Not a mistake I made, but still a helpful hint: The dark-slide, which blocks light from hitting the film until you pull it, has an “exposed” side and an “unexposed” side. Before turning off the lights, know which is which. The handle of the “exposed” side feels different.

Two: Know how to load the film before you get into the pitch black laundry room darkroom. There’s a flap on the end of film holder — it’s on the opposite end from the dark-slide handle — and it flips open for loading. You slide the film into this end and then flip it closed after loading. Load gently without actually touching the film. You figure that one out.

Open the film door after pulling the dark slide (Click for larger)

Loading the film (Click for larger)

Three: Have everything between the camera and the ground tightened down as much as possible before loading the film holder into the camera. Unlike 35mm cameras, you load the film at the last moment by pulling the spring-loaded ground-glass away from the camera and sliding the film holder between it and the bellows. If something isn’t tightened down, the scene that you photograph will look different than the one you composed. In my case, I locked down all of the tilt, shift and swing knobs and the tripod pan, tilt and swivel controls, but I hadn’t adequately tightened the quick-release plate onto the camera before mounting it to the tripod, so the whole camera turned quite a bit while I loaded the film.

Four: Know your film’s ISO speed in the field. There’s no ISO dial to set, just a number that you enter into your handheld lightmeter. I couldn’t even remember what kind of black and white film I had: T-Max 100 or Tri-X, which I thought was 400. I split the difference and said 200 ISO, which was close to the real value of 320 but not perfect.

Now I just have to figure out how to develop the film that I exposed today. . . .

Posted in Large Format Camera, Life Lessons, Photography | 4 Comments