It’s been a long time since I’ve heard the term “Structured Walkthroughs”. Back in 1978, Edward Yourdon wrote a book by that name. I have the second edition of “Structured Walkthroughs“. It’s a good book. It gives you a good, human-perspective approach to critiquing other people’s work–that can get tricky sometimes.

In the late 90s, while working on large, client-server projects, we would walk a fellow coworker through our work and explain to them our approach for solving the problem we were working on. Usually, this person would be the technical lead or a more senior developer. For the most part, my walkthroughs were easy and I quickly learned the common techniques used in that shop. I was fortunate to be working with good people. That certainly makes life easier.

One habit I picked up was anticipation. As I coded, I began anticipating what my fellow coworkers would say about the solutions I was arriving at. This anticipation improved my code with respect to their standards. It made the whole process more efficient because I had less changes to make after I was done. Eventually, the quality of my code started to improve to the point that it was rare to find a bug in it. This fact didn’t go unnoticed. I got a reputation for turning in perfect code.

However, there was a small price. I ended up turning in my code a little later than most. Not much later, but enough that it didn’t go unnoticed either. I took a little extra time because I was anticipating–anticipating the walkthrough but also the QA and ultimately the customer’s looking at my finished product. I wanted it to be right–always.

Here’s a timeline graph of when thing happened with my code with respect to other developers:

Figure1: Productivity Graph

While my first delivery to QA was typically much later than most of the developers on the team, my overall delivery to the customer was much sooner because my work spent less time in QA. You can show this graph to a project manager and they’ll understand what’s going on. Doing it in real life however is a whole different story.

“Why isn’t your code in QA yet?” they’ll ask. If you’re anticipating and creating quality code, just smile and say, “it’s coming” and don’t worry. In the end, you’ll have a better result. I always do without fail.

One of the best lessons I took away from the Yourdon book was about games. Chapter 9, “Games Programmers Play” was an extension of the classic book by Ernie Berne, “Games People Play”. Basically, there are patterns that people operate under that help them to avoid responsibility for the work. Look up transactional analysis if you’re curious about these games.

However, the lesson I learned wasn’t so much about other people’s behavior–it was about mine. I learned to recognize when I was playing the games and avoiding the truth about the problems that I was solving. This helped me to stop playing the games. My productivity improved. This made life easier as you can imagine–improved self-esteem, confidence, etc.

So, the next time you get stuck with a problem or are about to turn over some code, stop playing games, grab a coworker and take them for a walk. And if you can’t find a coworker, pretend and go for a walk anyway. Over the years, I’ve created a faceless, relentless uber-coder comprised of all the authors that I respect that I take on walks through my code. He’s not for the faint of heart but if he joins you, your code will be the better for it. Give him a try sometime (imagine a deep, echoing laugh . . . moo ha ha ha).