A Tale of Two Engineers

There were two engineers who had to work on the same product.

Dave was an expert in server code and Francine was an expert in client development.

Naturally, the work that Francine did affected Dave by influencing how the system he maintained would be used. Vice versa, Dave's work affected Francine by altering how a dependency of her code behaves.

They decided to meet once a week to make sure they were staying in sync.

After the first week, they had their meeting and discovered that each had made many assumptions about what the other was going to do. They came up with a list of changes and spent the first day of the next week resolving the discrepancies.

This continued for a month; each Monday was spent reconciling the changes made in the previous four working days.

"Francine," said Dave, "this is costing us a lot of time. Maybe we should only do it once every other week."

"That's a good idea," said Francine.

Two weeks later, the meeting and the changes required to integrate totaled three days.

After a quarter of consistently spending thirty percent of their time integrating their work, Francine said "Maybe we should only be doing this once a month."

The cost of resolving their changes again increased. In any given twenty-day period, a full ten working days were consumed by the integration effort.

Dave and Francine went to their manager and told him of the problem. The manager suggested that they integrate twice as often.

Francine looked horrified and Dave's jaw dropped open.

After a long pause, the Dave finally spoke.

"Are you crazy?" he asked, rhetorically. "We already spend half our time integrating our changes."

"So?" asked the manager?

The two developers exchanged looks.

Eventually, Francine explained. She spoke very slowly, as if to a child "We spend half our time integrating our changes. If we do it twice as often, we won't have any time left."

A Personal Example of Changing Mindset by Creating a Habit

A few years back, I wanted to start eating steel-cut oatmeal for breakfast. I had high cholesterol. I believed this lifestyle-change would impact it in a beneficial way. If I was right (I was) it would obviate the need for statins.

After languishing in excuses for a while, I decided it was a matter of discipline. I was going to do it. I would eat oatmeal every day for a week.

How Can I Test this Code?

Early in a test-driven development transition, a lot of people want me to make TDD work with their code.

"What you showed me was fine...great, even...but how can I make this work with my existing code?" they ask.

When we go look at their code, most of the time the answer is "You can't and that's a good thing".

One Way Design Patterns Help

Design patterns can help a team by facilitating high-value communication about design.

Arguments for Encapsulating Constructors

I always encapsulate my constructors. That is, given the following two designs (C#), I choose the latter whenever I can:

// this...
class A { }

// ...or this
class A {
  A() { }

  public static A GetInstance() => new A();
}

A Trick for Retraining Yourself

Previously, I suggested that one way to change your mind is to start with a discipline, evolve it into an habit, and let the habit reprogram your thinking.

Getting through the discipline phase can sometimes be challenging. In my experience, old habits try to reassert themselves a lot in this phase and sometimes they succeed.

When this happens, one trick that I used was to always undo whatever I did and redo it using the discipline I'm adopting.

Software Development Thinking Applied to the Real World, Part I