Programming == tree-traversal?

It occurred to me the other day that programming is kind of like tree-traversal. Computer scientists know this but tree-traversal is the process of visiting every node in a tree structure in a systematic way. As I design and implement software, I often find myself doing exactly that.

During software design, I start with a simple design where there are no decisions to be made. (or the decisions have obvious answers.) At some point, I need to make a non-trivial decision about the design. There are often multiple answers and there is no single best answer. That’s like getting to a point where you need to take a left, middle, or right path in a decision tree. Once that decision is made, you continue the design process with the constraints of the initial decision, and another point comes along where you need to make another decision. This is another split in the decision tree, one level below the initial split. You make that decision, (one more level down in the tree) the process continues until you reach to a point where the previous design decisions lead you to a dead-end. Dead-end can be considered as a node where you are not happy about design anymore. Maybe you found out that technically something is not possible to implement, (or very-hard to implement as nothing is impossible in software) so you need to change some or all of your design decisions. This is like back-tracking high enough up in the decision tree, finding the split that led you to the dead-end node, and remaking the decision at that point. You continue the tree-traversal (design decisions) until you’re at a node where you’re happy with the design.

The same can be said about implementing software. There are many points during implementation where one decision like a data structure choice, or an algorithm choice, constraints future decisions, and one wrong decision can cause you back-track a series of previous decisions. You are going through decisions trying to find the medium where you are happy about the implementation trade-offs you’ve made, very much like finding a node in tree-traversal.

I know this might sound obvious and most of us subconsciously are already doing the design and implementation like tree-traversal, but I do think that it’s beneficial to remind ourselves what we might already know as we’re designing and implementing things. I’ve been certainly finding it helpful (and more recently necessary) to remind myself to map out my design and implementation decisions as a tree-traversal problem. This way, I can mentally map my decisions better, back-track my decisions when I need to easier, and most importantly, I am constantly reminded that software design and implementation is not (and should not be) a haphazard process, it can rather be as orderly as traversing a decision tree.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s