Amy Is Four

Actually four years plus six days, but who’s counting. I only took a few pictures, and a little video (later), but here’s my favorite from that day.

four-year-old Amy

Just for fun, here are a couple of bonus pictures. First, here she is trying to eat a bubble in our back yard. Actually I think she got the one she was going for, and the one still in the picture was next on the menu.

eating bubbles

Lastly, here she is at her new favorite playground in Lincoln. Lexington used to have one of these wooden maze-like playgrounds, but they replaced it with a more modern type. Despite the splinter problem, I kind

of like these ones and they’re becoming hard to find. Heck, the Lincoln one was hard to find, even though we could see it from the road. It’s a particularly elaborate and impressive example of the genre, with different parts having distinctly different motifs – a car, a train, a turtle, a horse, a little obstacle course, and the “pirate cabin” where this picture was taken. Amy likes to have me stick my arm in through the “porthole” and pretend I’m a sea monster. Good times.

pirate cabin

Looking at her expression, you probably wouldn’t know that taking a picture was actually her idea.

The Importance of Testing

For the last few weeks, I had been making fairly major changes to one of the components I’m responsible for at work. Functional and stress tests were passing, so I figured I’d test performance a little to see if I’d introduced any regressions there. To do that, I needed to establish some baseline numbers using the current code. Unfortunately, I soon found that my standard performance “smoke test” was flaky even using the latest official (development, nor release) build. Uh oh. That was Thursday afternoon. I spent Thursday night, a frantic Friday, and then much of today (we had a planned power outage all of yesterday) trying to figure out where things went awry.

As it turns out, the problem was from another change I had made to another component weeks ago. This was a great relief, because that will have almost no impact on my last few weeks’ worth of work. If it had been in the same component that I’ve been working on, I’d be looking at some very tedious work disentangling the long-ago changes that caused the problem from the later changes that were based on the changed code. In a way, I dodged a bullet, but this does underscore the importance of testing early and often instead of just writing huge globs of code and then testing only at the end. It also suggests a new kind of rule for how much effort should be devoted to testing during development: in addition to considering the usual magnitude or risk associated with the changes you just made, you should also consider how many future changes will depend on the new version and how much pain you’d be causing yourself if a problem introduced in an early change only showed up while testing a later one. It’s common sense, really, but so is a lot of software engineering. Common sense often doesn’t become common until it’s reinforced with a few “negative lessons” from real life. Learning from your mistakes is great, but learning from other people’s is even better.

Spam, spam, spam

The spam is back. Comments are moderated again until this storm abates.