Optimizing the Chore

Jennifer lived in a three-story townhouse in a very crowded city. It took forty-five minutes to drive one mile to work in the morning. It took another forty-five minutes to drive back at the end of the day.

On the days when it was her turn to drop off the kids at school, things were a little worse. She needed to drive her kids a half mile to the school, followed by another mile and a half to go back.

In addition, she had to stop at a drive-thru and get her children breakfast. Like everything else in the city, the drive-thru had a very long line and a very long wait.

At least the kids could eat in the car, though. That saved Jennifer a little time.

All told it took her three hours to get to work on those days.

She couldn't be late to work, so she had to get up earlier on the days when she was supposed to take the kids to school.

Her husband had it even worse, so she couldn't just have him do the dropoff every day.

The children were very tired, getting up so early for school and they were very cranky when she picked them up, after, because they had to wait so long for her to finish work and collect them. This meant that getting everyone ready took even longer than usual.

They tried getting a smaller car so they could zip in and out of traffic. This was surprisingly effective. It cut an average of five minutes off her daily commute when she didn't have the children and a full ten out of her roundtrip when she did.

They tried getting a faster version of the small car so Jennifer could exploit even more of the open spaces. The returns were diminishing, saving maybe a minute each direction.

They tried working harder to get the children ready in the morning. They acted like drill sergeants and Jennifer's daughter and son were both miserable, but the savings were a whopping fifteen minutes a day.

Every time they tried to make the commute easier, they either had little effect or no effect. Eventually, the changes started to turn against them.

The city's traffic problem was getting worse, as they tend to do. The children began to push back, as they tend to do. The police began to take notice of the hyper-aggressive car following the same short route every day, as they tend to do.

One day, while she was trying to force a shirt onto her son, he asked the obvious question. "Why do we sit in traffic?"

"Because that's how we get places," answered Jennifer.

"...but school is so close," said her daughter. "Couldn't we walk there faster?"

"Well," thought Jennifer, "I guess we could."

"...and couldn't we just walk in to get our breakfast?" asked Jennifer's son.

"Probably."

After they were ready, they put on their warm coats and left for school. A few minutes later, they were at the fast-food restaurant they frequented for breakfast, every day. While the line in the drive-thru was very long, the lobby was nearly empty.

They stepped right up to the counter and ordered. They were surprised by how quickly they were served their food and they finished their meals in less time than they spent waiting in line, the day before.

They departed and headed for school, which took a few more minutes. After dropping off her children, Jennifer was able to walk to work in less than half an hour...and she felt great.

Instead of spending her time clawing and grasping for position, she strolled down the street, planning her day.

That night she told her husband about her revolutionary life-changing discovery. She offered to take the children every day so his commute could be a little easier. It didn't take long for her husband to follow suit, walking out of the knotted-up downtown traffic and catching a rideshare the rest of the way to work.

It's not always this obvious, of course, but we all have little things in our life that we expend time and energy trying to make easier when, instead, we should be trying to not do them at all.

Anecdote: Broken Glass and Bare Feet

One of my cats shattered a vase, the other day...and I mean shattered.

Should Order of Changes Affect Design?

Let's say you have to add three behaviors to your system, A, B, and C. They could be done in any order. In this hypothetical, you will learn exactly the same set of things as you implement them, regardless of order. So your understanding at the end of those three stories will be the same no matter what.

There are six paths you might take...

• A, B, C
• A, C, B
• B, A, C
• B, C, A
• C, A, B
• C, B, A

Should the choice of order affect the final design of the system?

Note: I'm not asking if it will or can, the way things are, now. I'm asking if it should.

I don't think it should. I think that the point of software design is to attend to the forces in your problem space. I can't see why the order of introduction should matter.

Procedural and Environmental Approaches

I have a friend, Eran Pe'er, of DevCraft, who likens refactoring to the procedures and preferences of Brazillian Jiu-Jitsu. I don't know much about Brazillian Jie-Jitsu but I know about this way of thinking.

Every situation has a list of situations that are better than it. The transitions between certain situations are well-defined and can be learned, practiced, and shared. It's a good analogy for a style of refactoring. In this style, it is the procedures of transformation which give us our safety. A nice property of this is that it is environment-independent; you can do it with or without a meaningful battery of tests.

A procedure lets you make your situation better in a relatively-predictable way

I have a different approach; this was especially the case before I met Eran. For me, getting to the suite of comprehensive, executable specifications is what it's all about. For new code, that's easy. I just don't write any behavior before I've written a test. For legacy code, it can be more challenging. However, once I've attained the right body of tests for some code, I can refactor with impunity.

I don't care if my changes are proved to be transformative because, with NCrunch, I'm always about three seconds from finding out whether or not they were safe. For me, the focus is on creating an environment where refactoring is always safe regardless of how disciplined an approach I take.

The right conditions make certain problems irrelevant

This difference in emphasis is interesting to me. For one thing, they both have a common ancestor: culture. Neither of these methodologies can be installed without a fertile culture. For another, they both work.

A lot of people would look at two things that work and ask "which one works better?" A seemingly-natural impulse for us is to make two ideas compete so we can choose a winner. My inclination is to find a way to combine them into something new - a third option that keeps the best benefits and leaves behind the worst drawbacks.

I've been experimenting with applying discipline-focused refactoring to my own work. To be clear, I'm not giving up what I already do. I'm just adding his style to the way I already work. I'm not sure it's speeding me up but it's also not slowing me down and I've only just begun to practice it. With a few more weeks, familiarity will develop and it may well be faster.

There's something interesting there. You can combine them (at least in one direction) without any slowdown. There's a compatibility, there, that implies they are complementary techniques.

Agile Speed

People seem to mistake the point of a lean or agile process's claim to deliver quickly.

They think it means "get people going fast" or "get people working harder". Reduced to its essence, the interpretation is often some form of "get people doing more".

Yet, most of the agile claim to speed is not in how fast someone works. It's in how much they don't do.

Vestigial Inheritance

Favoring object-delegation over inheritance as a way of sharing traits between classes is a field-proven technique. So many people "invent" that technique while they are learning that it's hard to trace it to its true origin.

Certainly, the Gang of Four did a lot to popularize the notion.

Yet, there are little places where people still tend to trip and fall back into inheritance as a way of sharing commonalities.

Software Development Thinking Applied to the Real World, Part IX

The conclusion of the story arc but not the end of the comics.

(last week)