Understand The Memory-Factor — A Quick Workshop To Faster Development.
As a little boy, I went to an idyllic yellow wooden elementary school. The school had its kitchen, where Martta cooked lunch for us, and only a handful of students attended each class. No worries about the covid back then.
We started learning our first foreign language during the third grade. English classes began with basic vocabulary, and we all gave ourselves English names.
My name was Andy, while my friend Aki wanted to be known as Jake. He was a big fan of the TV series “Jake and the Fatman.”
When you learn new languages, you quickly reach a point when you start practicing small conversations with friends in the class. The first conversations between Jake and me went something like:
Hi. My name is Andy.
Hi Andy. I’m Jake.
You can learn a lot from these dialogues, and you also get fast feedback from a friend.
But what if you took that exercise to the context of modern software projects?
If you were a coder, here’s what would happen.
First, you make a change to the software and commit code to version control. Three weeks later, when the next patch goes live, someone finds a bug. The bug report returns to your desk a month later, and you start to investigate.
In this context, the critical question follows. Do you still remember where you were and what you did at this time, three weeks ago? Very few people can answer this question. The ones who can remember usually were in an emotionally engaging situation like a root canal operation at the dentist.
You can experiment on this memory-factor by asking how many of your friends remember the 9/11 incident when the WTC towers collapsed. Most people have a vivid recollection of that day, even though it was 20 years ago.
It is unlikely that you develop software with such enthusiasm and emotion that you remember which parts of the source you touched those three weeks ago.
It’s a bit like you were trying to study English alone. “Hi. My name is Andy,” and then everything goes quiet for three weeks before the answer arrives. “Hi. Andy, I’m Jake”. Nobody learns anything and it’s hard to remember details or the context of a dialogue like that.
Human memory plays a huge role in software development.
As I see it, here are three of the most significant implications of this memory-factor.
#1: Finding the root cause for a bug is like browsing through a box of old family photos in Grandma’s attic, trying to find one specific pic. If you don’t remember what parts of the code you touched, or the dependencies, here is the question. Will it take more or less time to make a fix? Will there be more or less risk for regression errors to appear?
#2: Is it possible that someone else has written code based on what you created weeks earlier? If it is, what happens when you start fixing that bug? Is there more or less risk that the fix breaks something else somewhere else in the system?
#3: Fast-paced and flowing dialogue promotes learning new languages. Getting fast feedback helps both participants to learn. The same applies to software development too. So it boils down to this question. Will learning make your coding faster or slower?
The answers to the questions in the previous three points are obvious, of course.
The solution to leverage the memory-factor to your advantage and continuously make development better and faster is simple.
A fast and accurate feedback channel from spotting problems to fixing them is paramount to success.
The sooner you find the bugs, the quicker and more reliable it is to fix them. And that saves the precious time of your developers for something more productive.
Fast feedback promotes learning and makes fixing faster.
Fast feedback plays a critical role in getting results. Fixing issues is quicker and less risky. Not to mention speeding up the learning process! Here are three steps that you might want to walk through in your next retro.
Step 1: Draw the timeline
- Think about yourself as a coder who just completed a task of coding.
- Take a paper sheet and draw a timeline from coding to go-live. You can do this on whiteboard too with some post it notes for a bigger workshop.
- Mark all essential phases that the code goes through before it’s out.
Step 2: Find feedback loops
- Look at your timeline and draw a feedback loop in all places where you, as the coder, are currently getting feedback.
- For each feedback loop, estimate the time it takes for the feedback to arrive on your desk. Include customer feedback and support tickets too!
Step 3: Improve
- For each of the existing feedback loops, is there something you could do to make it faster and shorter?
- Are there points on the timeline where you could create new, fast feedback loops? Think about things like automatic unit tests, task-specific exploratory testing, cross reviewing code, etc.
Finally, ideas are worth nothing if nobody takes action. So, take the first step toward improving. Or, if you can’t do it now, block out some time in your calendar to get moving.