There’s a lot of be said for including a tester (or two) early in the software development life cycle. They can spot potential problems or things that might frustrate users that developers might have overlooked. But according to a blog post by James Bach, there’s also something to be said about having a tester (or another developer, or just someone who’s curious) sit in on the actual coding process.
Before you get all up in arms hear James out. This isn’t an endorsement for always having someone looking over your shoulder and it certainly isn’t practical in every situation (especially with longer term or quick turn around projects). It’s more of an interesting exercise that both parties can use to gain a better understanding.
Here’s a little background on the revelation. James was working on a project with his non-developer, non-tester sister. Part of that project involved James writing some code. He invited his sister to sit in while he was coding and discovered that by narrating his actions and answering her questions he slowed down and took a deeper look at what he was doing. (You can get the full backstory in his post). Here’s a few takeaways from the original post:
She found six or seven important bugs while I typed, and many other little ones. The programming was more fun and social for me. I was more energized and focused. …
She didn’t just look at my code. She looked at my code in the context of me talking to her about what I was trying to do as I was trying to do it. The process unfolded bit by bit, and she followed the logic as it evolved. It doesn’t take any specific personal quality on the part of the “coding companion,” just general ones like alertness, curiosity, and basic symbolic intelligence. …
James boiled it down to three key factors that made this impromptu collaboration so successful.
- The dynamic and interactive legibility of the coding process. … I tell him what and why and how. I do this repeatedly, and answer his questions along the way. This makes the process accessible (or in the parlance I like to use “legible” because that word specifically means the accessibility of information).
- The conceptual simplicity of many bugs. … As I fix my own bugs and narrate that process, my coding companion begins to pick up on regularities and consistency relationships that must be preserved.
- The sensemaking faculties of a programmer seeking to resolve the confusion of a companion. … When my coding companion says “I don’t understand why you put the dollar sign there and there, but not over there” my mind is directed to that situation and I need to make sense of it.
Be sure to read the entire post on James Bach’s Blog >>>
It’s an interesting concept and could be useful for both dev and testing teams. It’ll help both parties understand (and potentially change) the work habits, approaches and assumptions of their co-workers. And ultimately, sitting together, talking and working on a piece of code will give both teams a more aligned understanding of what the final product needs to be and how it got there.
