ABCDs From an Arborist

As with most any large or complex system, one of the unending tasks of home ownership is maintenance. While I am relatively handy with the infrastructure, I have found the hard way that is best for me to hire expert help when it comes to the outdoors. Luckily, I have an arborist that is happy to help out when the hedges become hellacious, and the bushes harbor on boundless. I mentioned to him that I can look at an overgrown thicket of a rhododendron, and just... not know where to start.

"Ah! That's because you don't know what order to do it in! You have to follow the Four Ds: dead, diseased, downward, deranged."

That sounded suspiciously like a process with a mnemonic, so of course I latched onto it and asked for more information. He said that these four categories of how to approach the overgrowth were also the stages for cleanup:

1. Dead: Prune it away, don't even think about it.
2. Diseased: Prune it away if you have to (and you most likely will), but you may be able to treat it as well, to prevent it from spreading. Worst case, uproot and replace the plant.
3. Downward (anything going 'the wrong way'): May be able to retrain it, but if not, prune it - it will absolutely be more trouble than it's worth to try and maintain it later.
4. Deranged (entwined or curly branches, crazy growth patterns): Most of the time, it's one to prune, but every so often, after completing the above steps, you find some interesting shapes that are worth saving and incorporating into the plant's future.

I tried his advice, and it worked wonders. You have to complete each stage before starting on the next one, regardless of how tempting it may be to jump ahead. This not only helps focus the work at hand, but each stage clears away cruft and uncertainty that obfuscates how the remainder of the growth should be handled. Skipping steps, or jumping around in priorities makes the overall job much harder than it needs to be, because that deranged branch may, in fact, simply have dead ends that you can't quite tell at the moment due to other foliage obscuring your view. Manually tracing each branch outward is time consuming, error-prone, and just tedious. It's entirely too easy to get lost in the details, instead of keeping the larger shape of the shrub in mind.

It didn't take me long to realize that the approach he described is very close to how I tackle large or complex software systems:

1. Find the areas that are not used, so they can be eliminated from consideration, if not eliminated from existence.
2. Look for functionality that does not work as intended (version control hotspots are great flags), or perhaps that does not work as well as it should (team interviews are good here). Triage to streamline what you can, fix what is fixable, toss and replace what is not.
3. Search out those portions that perform their task just fine, but it's the wrong task. It may be a requirement that is no longer relevant, or a misunderstanding of what the needs are. Perhaps it's a design decision that is at odds with the rest of the codebase's roadmap. Anything that is not aligned with the direction the project is headed. Refactor, rework if possible, remove and replace if not.
4. Finally, look for those places that make you scratch your head and mutter obscenities. These are the spots where either genius or insanity reside, where that grody bit of code that no one really understands is either an unnecessary blockade to comprehension, or, every so often, a critical piece of arcane magicks that the entire system relies on.

At each stage you are focusing on one aspect of the task of comprehension:

1. Find the boundaries of what you need to understand.
2. Understand where the well-understood issues are likely to be creating pain points.
3. Identify where the necessary issues were not well-understood (or have drifted out of sync with the reality of the system).
4. Get to the chewy, fun bits that when resolved will provide the client with the greatest value, either by eliminating a Gordian mess, or uncovering a hidden gem that needs greater conscious awareness on it.

Even better, when attacked in this order, each stage clears away the cruft and lets you more clearly see the scope of the next stage before you. There's no point in attempting to fix, replace or understand code that is simply not used after all, so cull that from your search space first. (While the repeated emphasis on removing offensive pieces may cause some anxiety, I urge you to place your trust in version control for the historical record, and keep the current working state as clean and clear as possible.)

Having this process in mind has helped tremendously in streamlining systems analysis, and it's turned out to have application in other areas as well, such as automotive maintenance, property maintenance, and in my personal case, dealing with a residential plumbing system that follows no known Euclidean geometry.

However, the Four Ds – while applicable to greenery – have limited mapping to most other fields, so instead I've reworked them into ABCD.

• Abandoned - Anything that is disused, eliminate where ever possible.
• Broken - Where it is almost (but not quite) right, fix if possible, but remove and replace if necessary.
• Contrary - If anything in the system is contrary to requirements, contrary to expectations, or contrary to the roadmap, refactor if possible, replace or simply remove if not.
• Deranged - Whatever that is left that makes you cock your head in awe (or fear), tackle it head on. This is where the biggest ROI for your effort likely sits, and once the above three are cleared away, it's easier to see its shape.

So that's the best advice I've received on systems analysis from my arborist. Follow the steps, focus your effort, and paths to open spaces will appear before you. Templates for good processes exist everywhere, it is often just a matter of seeing the patterns for the...

... trees.

Sorry. (Not really.)