In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set here. The next seven blog posts are expanded versions from “Seven Strategies for Splitting Stories”. You can find the original post here.
Rather than trying to figure out everything upfront before we begin coding, the Agile approach is to take unknowns with us into iteration so that we can resolve them there.
Many times, we’re not even clear on what we don’t know until we begin coding so in many ways that’s the ideal time to research unknowns. I know this can make some developers uneasy. They’re used to having an analysis phase and getting clear requirements that tell them exactly what to do. But when we are building something that’s never been built before, there are bound to be questions that we didn’t think of that come up during development.
When issues come up for me during development and I can’t move forward without resolving them I stop and focus my attention on resolving the issue. This is when I am most familiar with what I need, and I look for ways to answer my question as quickly as possible.
My goal is to shrink the domain of the unknown so that it gets smaller and smaller until finally it disappears and is engulfed by the known. Once I understand the missing piece, I can then implement and integrate it into the rest of the system.
There are times that we do not know what we don’t know. I just spent several hours trying to ramp an audio frequency, only to find that there is an audio library that will do this for me, so I didn’t have to implement it myself. It’s part of HTML 5 so it’s guaranteed to work correctly on all (most) browsers. Finding this API save me an enormous amount of effort and time.
One of the first things I do with any unknown is that I try to encapsulate it. In other words, I try to draw a border around the area that’s unknown so that it’s separate and distinct from the things that I know. If I can encapsulate the unknown by hiding it and making it appear to the rest of the system as a generic service with no side effects, then I know I can deal with that unknown later, and when I do it won’t affect any of the existing components that I built. When I can encapsulate an issue by creating a strong contract with a well-defined interface, it means that that issue will not leak into the rest of my system. Most issues can be encapsulated in software, so I use this approach all the time.
There are times when an issue is so big and all-pervasive that it is not possible to fully encapsulate and when I encounter issues like that I stop what I’m doing immediately and focus all my effort on resolving it. Fortunately, I don’t encounter these issues frequently.
Moving into iteration with unknowns was a scary thought for me at the beginning of my career as an Agile developer. But I’ve gotten used to it and now I find that I can figure things out more readily in the middle of an iteration than I could in the planning cycle, so I spent far less time planning and far more time coding.
Previous Post: « Break Complex Stories Down into Knowns and Unknowns
Next Post: Seven Strategies for Product Owners »