Wolves and Software Development

“…it seems appropriate to label one way the right way and the other way the wrong way.”

Years ago I heard about a Native American story about two wolves constantly battling each other inside each one of us. One wolf has a positive attitude towards people and life, the other negative. The question came up, which wolf wins? The answer is, the one you feed. I can see some truth to that. Negativity can cause more negativity, whether in the same person or other people. Being positive can be somewhat contagious as well. Self-help books point out that we tend to think in the way that we practice. But is the lesson of the wolves just for how we approach life?

The subject of computers certainly has its share of dichotomies such as bit values zero and one, hardware vs. software, or connectionist vs. symbolic AI. I myself have experienced a dichotomy in two opposing approaches to software development – the “quick and dirty” way and the “proper” way. The quick and dirty way involves things like copy and paste, oversized routines and modules, and short obscure names. The proper way involves reuse of code, single-responsibility routines and modules, and good naming practices.

Does the two-wolves story carry over to software development? Strangely, it does seem that way to me. When considering how much is at stake in terms of saved or wasted time on a nontrivial project, it seems appropriate to label one way the right way and the other way the wrong way. On a given project, I have found that the more code that is done right, the easier it is to keep doing things the right way, when I fix or add to the code. Conversely, the more code that is done the wrong way, the easier it is to make changes the wrong way.

For example, if some logic that is needed in multiple contexts is in a single routine that is called from those places, the code is easier to understand. It is already easy to reuse that logic in additional places. On the other hand, if the same logic occurs in several locations, that can make the code harder to understand, partly because of additional clutter. When adding that logic to a new location, it might be more convenient to create yet another copy of the logic. Trying to figure out what all the code does is harder, since the existing duplication makes it more complicated. It’s easier to copy the code and be done and not worry about breaking existing code. Why not move the logic in at least one case to its own routine so it can be used? Doing so could cause additional confusion, as someone may wonder in the future why the same routine was not called from those other locations too. This can even lead to fear of improving the existing code, allowing the code to get worse with future changes.

So bad code can encourage more bad code, just like good code can encourage more good code. Consider also that coding one way or the other can build good or bad coding habits. It seems the story of the two wolves applies to software development after all. So, within each developer are two wolves who are constantly fighting each other. One represents writing software properly, and the other represents taking the quick and dirty approach. Which wolf wins? The one you feed. Some traditions are still relevant, even after centuries and even in new situations.

(c) Copyright 2019 by Mike Ferrell

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Leave a comment