Hill Climbing and Hill Searching
Micro-focused refactoring is a strategy like hill climbing. When done well, it leads to the best (or sufficient) local design (peak of the hill).
The localized hill climbing strategy doesn't, however, ensure that you're climbing the highest hill. We may arrive at the best design for the given context (the peak of the hill), but not at the optimal, or at least an overall acceptable, design (highest hill). (This is referred to as a "local maximum.")
If the wrong hill is chosen, there is some cost in retracing our steps back down some or all of the hill (rework). The higher the hill and the more we climb before noticing there are higher hills, the greater the added journey to get to the better hill (the more complex the problem and the deeper into the implementation we get, the more the rework costs). We can only hope we don't run out of daylight before we can climb back down and ascend the better hill (analogy left to the reader ;-).
Macro-focused design is a strategy like hill searching. It provides a better vantage point to look for the highest hill (optimal, or at least better, design).
However, we need to have a good view of the mountain range (context) in order to search for the highest hill. If we have a clearly known context, with a known set of hills to search (known set of design solutions, a.k.a. patterns), we can find and choose the optimal design solution/pattern (hill to climb).
Because of the cost of retracing our steps (rework), and the amount of daylight left (resources), it's a good idea if we can find a vantage point and scan for the higher hills before we start climbing. We could save a lot of climbing and retracing this way. By recognizing the obvious contexts of our problem, and by researching the canonical solutions (patterns), we can significantly reduce the risk of rework.
If we don't have such a well defined context, with canonical solutions, then searching for the highest hill can be speculative and a waste of time. In these cases, it's probably better to just pick the highest hill we can see and start climbing. Maybe on the way up we'll notice a higher hill (learn something new), or determine we're on a good hill after all (good enough). But there's really not many hills that haven't been climbed these days.
Once chosen, the highest hill is still climbed a step at a time (with a micro-focused, test-first refactoring strategy). We take the most direct route, pausing for refreshment as needed, and stop when we reach the peak (sufficient solution). It's a good idea to stop occasionally and take a look around as well, just in case there's a higher hill that's appeared over the horizon. Sometimes we find that the hill has a little slope attached to another hill, and we end up on a different hill than we thought we would at first.
When hill searching, the ideal case is to choose the best hill (optimal design). But we also want to be conservative in choosing. There's no point in choosing a 12,000 ft. hill when we only need 9,000 ft. of altitude. The design choice should be the simplest, but sufficient, one that fits the known requirements.
Especially when there's uncertainty, either about the context or requirements, choosing smaller hills (simpler designs) reduces risk. If the design turns out inadequate, there's less to rework. If it ends up doing the job, it should be one of the simpler (and cheaper) solutions, and we win for doing less climbing (work).
When there's great uncertainty, we can just start climbing any convenient hill, one small step at a time. As we climb, it would be prudent to keep scouting just how high the hill we're climbing really is, and if there are any promising adjacent hills, before we get too far up. If we need to, we can always send up a lone climber to check out the route before we send the whole expedition up there (design spike). Being adaptive means being able and willing to change course, even double back, at any time (that courage thing).
Climbing in pairs can reduce risk. While one climber is focusing on the hand holds and making sure the ropes are secured, the other can be scouting the route and scanning the horizon for better hills. When things get dicey, they can consult. If one climber slips, the other can grab the rope and pull them up.
/Paul Hodgetts
Bookmark this link to this article.
Do you have feedback or questions? If so, please send us email at feedback@agilelogic.com.
|