Truly Agile Software Development

Truly agile software development has to, by nature, allow for experimentation. In order to quickly assess the best option among a number of choices, the most effective method is empirical evidence: build a proof of concept for each option and use the experience of creating the proof, as well as the results, to determine which option is the best for the given situation.

While unit tests are valuable for regression testing, a test harness that supports progression testing is at least as useful. Agile development methodologies tend to focus on the idea of iterating continuously toward a goal along a known path; but what happens when there’s a fork in the road? Is it up to the architect to choose a path? There’s no reason to do so when you can take both roads and decide afterward which you prefer.

Any large development project should always start with a proof of concept: a bare-bones, quick-and-dirty working implementation of the key functionality using the proposed backing technologies. It doesn’t need to be pretty, or scaleable, or extensible, or even maintainable. It just has to work.

Write it, demo it, document what you’ve learned, and then throw the code away. Then you can write the real thing.

It may seem like a waste of time and effort at first.  You’ll be tempted to over-engineer, you’ll be tempted to refactor, you’ll be tempted to keep some or all of the code. Resist the urge.

Why would you do such a thing? If you’re practicing agile development, you might think your regular development is fast enough that you don’t need a proof. But that’s not the point; the point is to learn as much as you can about what you’re proposing to do before you go all-in and build an architecture that doesn’t fit and that will be a pain to refactor later.

Even if it takes you longer to build the proof,it’s still worth it – for one thing, it probably took longer because of the learning curve and mistakes made along the way that can be avoided in the final version, and second because again, you’ve learned what you really need and how the architecture should work so that when you make the production version you can do it right the first time, with greater awareness of the situation.

This approach allows much greater confidence in the solutions chosen, requiring less abstraction to be built in to the application, which allows for leaner, cleaner code, and in less time. Add to that the value of building a framework that is flexible enough to allow for progression testing, and you’ve got the kind of flexibility that Agile is really all about.

Note: Yes, I understand that Scrum calls prototypes “spikes”. I think this is rather silly – there are already terms for prototypes, namely, “prototype” or “proof of concept”. I’m all for new terms for things that don’t have names, but giving new names to things that already have well-known names just seems unnecessary.

Driving Algorithm

Yes, I drive by algorithm. I’m a programmer, and generally have an analytical mind. I can’t help it. Here’s what goes on in my head when I’m behind the wheel.

My top priority is awareness. I may drive like it’s a video game, but I do realize it’s the sort of game in which you only get one life. I’m constantly looking around as if I’m about to make a lane change. I try to have a picture in my head of where every car is, and how they’re moving in relation to each other and myself, so I can predict where they’ll be. If a car appears where I didn’t expect it to be, I’ve already failed.

Beyond that, it’s very much like a video game, in several different ways. Like many games, I need to assess my fellow players: who is being aggressive? They’re likely to accelerate suddenly, and take advantage of small openings to make lane changes. I need to be careful around them and keep an extra close eye on them, but I also know they’re not a bad person to be behind. Who is being cautious? They’re likely to drive slower and leave more following distance. I don’t want to be behind them, but I know their habits mean that they’ll provide ample safe lane change opportunities in front of them. Who’s being reckless, or not paying attention, or not maintaining lane? They’re a hazard, and I need to keep my distance and pay close attention to them. I also pay attention to what they’re driving: I know a sporty car is going to accelerate more quickly than an older car, a large truck, or a minivan.

I also need to know the map: is there an on ramp people will be merging from? Is there a lane that ends or becomes turn only? People will be leaving that lane, possibly suddenly if they aren’t familiar with the area. Is there a lane that backs up due to people turning? That lane will be slower, and people are likely to dodge into the next lane to get around the traffic. Any situation with a split, where one lane goes one way and the next lane goes another way (a fork, a turn-only lane, an exit-only lane, etc.)? Both of those lanes will be slower the closer they get to the split, because of people making last-minute maneuvers when they realize their lane doesn’t go where they want to be.

I also need to maintain tactical awareness. If a lane is slower, is there a reason? A slow driver or a big truck that’s slow to accelerate? If a lane is faster, is there a reason for that? Is there genuinely less or faster traffic, or will the lane slow to the same speed after a few hundred feet? If two lanes are moving the same speed, will one become faster or slower? Maybe many people are leaving that lane, or entering that lane. One lane could have more gaps between cars; as those gaps close (I think of this as the traffic compressing), the lane will advance further than a lane without large gaps. One lane could also end up being slower, if there’s a large truck, or a stalled vehicle, or an accident.

Generally, I try to avoid changing lanes unless there’s some reason that the lane I’m moving to will end up being faster than the lane I’m moving from. All things being equal, I try to be in the lane I’m going to need to be in for my next turn/exit/etc. If I’m going to make a lane change, I’m going to take all of the above factors into account: will the lane actually end up being appreciably faster? Is there an opportunity to make a lane change, or will there be soon? Will there be an opportunity to get back into the lane I need to be in, by the time I need to be there? Or, if I’m moving into a lane that ends, will I be able to get out before it does? Would I be getting behind a slower driver that will keep me from advancing, even if the lane itself should be faster?
If I’m trying to get around one or two particularly slow vehicles, I try to plan the entire maneuver: getting out of my lane, getting ahead of them, and getting back into the lane once I’ve passed them. This requires awareness of my lane and the passing lane, and being able to line up both the lane exit and re-entry maneuvers.
Generally, in light traffic, knowing the other drivers and their cars tends to be the most important, because they have the biggest impact on speed of travel in each lane. In moderate traffic, all three factors are fairly equal, but map awareness has a bigger impact in general. In very heavy traffic, situational awareness becomes more important, in order to know which lane is (or will be) the least bogged down.
Yes, I honestly think this way while I’m driving. Also, I tend to sing along to the stereo. Be glad you don’t have to hear it.