What is wisdom? In order to answer this question, we will look into some ancient Jewish texts.
From the Talmud (Tamid 32A), compiled 1500 years ago:
“Who is wise? He who discerns what is about to come to pass.”
In other words, the wise man is the one who sees the consequences of his actions.
From Ecclesiastes (14:1), composed 2300 years ago:
“The wise man, his eyes are in his head; but the fool walks in darkness.”
Rashi, the medieval commentator (France, 1000 years ago), interprets his eyes are in his head to mean: “In beginning of the matter he foresees the outcome.”
From Pirkei Avot (2:10), written 1800 years ago:
“[Rabbi Yochanan] said to them: Go and see which is the best trait for a person to acquire… Said Rabbi Shimon: To see what is born [out of one’s actions]…
He said to them: Go and see which is the worst trait, the one that a person should most distance himself from…. Said Rabbi Shimon: To borrow and not to repay…”
In this case, a person who accumulates a debt which he will not be able to pay is the ultimate example of not being wise enough to foresee the future implications of your actions.
Wisdom and Decision Making
From the sources above, we conclude that the wise person is able to foresee the future consequences of his actions. Of course this ability is useful only if it is applied to the decision making process.
If at the present moment you have several possible courses of action and if you are able to predict the implications of each alternative, then you can choose the option that will produce the more favorable outcome.
The decision making process is very similar to a game of chess. It is a well-known fact that chess masters have the ability to foresee several moves in advance. This vision allows them to build a successful game strategy. In the case a chess master must react to a surprising move from his adversary, he is able to rapidly consider several alternatives, analyzing their likely outcomes, and choosing the best one.
Some artificial intelligence algorithms are also based on this notion of exploring the future consequences of present actions. For example, the Minimax algorithm builds a game tree in which each node represents a move. The algorithm tries to maximize its chances of winning the game, while at the same time it minimizes the chances of its adversary to win the game. This algorithm has been used to implement chess-playing programs, employing heuristics to evaluate non-final game states.
Wisdom in Software Development
But how is this ability to foresee the consequences of our decisions related to software development? From Wikipedia:
“Effective software design requires considering issues that may not become visible until later in the implementation.”
We could also ask: What characterizes high-quality software? Is this the ability to satisfy customer needs? Is quality the correct implementation of the requirements?
The answer is that correctness is just one of several software quality attributes. What about other attributes such as maintainability, extensibility and reusability? All of them have in common the fact that they address future needs:
Maintainability: In the future, the system will need to be maintained, for example to accommodate changes in requirements or to improve its performance. We would like this maintenance to be as easy as possible.
Extensibility: In the future, the system will need to be extended, for example to add new features or to support new functions. We would like these extensions to require minimum effort.
Reusability: In the future, we would like to reuse some modules of our system, for example to create a new product or support a new customer. We would like this reuse to be as simple as possible.
In other words, designing a system to be maintainable, extensible and reusable requires from software developers the capacity to plan for future needs.
But what happens if a team implements a system without taking in consideration these future needs? The answer is that this team is accumulating Technical Debt.
Technical Debt: The consequence of implementing poor design decisions in order to save development time. Like a debt is a value you know you will have to pay, technical debt is code that you know you will have to refactor.
As we have learned above from Pirkei Avot, a person who accumulates a debt which he is not able to pay cannot be considered wise. The same can be said about software developers who accumulate technical debt.
Conclusion
As we have learned from the ancient Jewish sources, wisdom means knowing the future consequences of our actions. Accordingly, developer wisdom means understanding the future implications of our design decisions. A programmer who is only concerned with the correct implementation of the current requirements cannot be considered wise.
What about you? Are you a wise software developer?
Effective Software Design 
Great post! I always cringe a bit when I see “YAGNI”, because sometimes, yeah, you are gonna need it. The quality of service attributes you list tend to be much harder to bolt on after the fact.
Thanks, Gene. I agree with YAGNI (You Aren’t Gonna Need It) in relation to product features: We should avoid adding to a product features that are not really needed.
However, Software Quality Attributes are not features. They should be seen as essential requirements of any professional software system. If a system will be used it will certainly evolve, meaning that it will need to be maintained, extended and reused.
First a nitpick on the interpretation of Tamid 32A: I’m no yeshiva bochur, but it looks to me a bit broader than that. I think it means to discern the results of *other people’s* actions as well, taking into account current circumstances. Your own actions may be irrelevant.
Second nitpick: entering into a debt you know you can’t repay is a very bad idea… *for those of us with a conscience*. We must always remember that there are evil (or at least excessively self-focused) people in the world. Many people would think nothing of entering into debts they can’t repay, because they’ll simply walk away from it, leaving the creditors stuck. Or they might figure they can stretch it out until past their deaths. Or, like many governments, they might figure that future generations will pay it off.
As for the rest of it, though, I just had to chime in with strong agreement! The first point of that is that stressing maintainability was one of the epiphanies I had early in my career. At first I just called it “giving a $#!^ about the next poor sucker who’s going to have to work on this code”… especially since it could be me! But since then I’ve refined it into a term, and yes, maintainability is it. One could even say that reusability and extensibility fall somewhat under this term as well.
Second point: at an interview, I was once asked what are the most important qualities of a piece of software. My answer to that is that though most people would rank correctness as #1, it has to be correctness *in relation to* something, i.e., the specs. If you ask me for a program that plays checkers, and I give you a bug-free user-friendly feature-packed *chess* program, you’re not going to be happy. Doing the right job is even more important than doing the job right.
Thanks, Dave. Your comment reflects another famous Jewish saying:
אֵין חָכָם כְּבַעַל נִסָּיוֹן
Or: “Wisdom comes with experience”.
I strongly support the sustainability message you derive, and enjoyed your use of Jewish sources, until a nagging thought crossed my mind… Wouldn’t it be straight forward enough to justify big-upfront-planning on the very same scripts?
“Who is wise? He who discerns what is about to come to pass.” – and perfectly describes it using Gantt charts…
Shalom, Guy, thanks for your comment. I think that Big Design Up Front (BDUF) is not always a problem. There are situations in which you may be able to freeze the requirements, and then complete the design before you start the implementation. This is the way engineers build houses and bridges.
In the case of software we know from our experience that it is very difficult to freeze the requirements. Thus we must plan for system evolution, including maintainability, extensibility and reusability.
So the real problem is not BDUF. The problem is the illusion that the requirements will not change. And in this case wisdom means not believing in this illusion.
You might be interested in this book a friend of mine just published. http://www.ybook.co.il/the_wisest_man
Thanks, David, the book sounds interesting indeed!
Pingback: Simplicity in Software Design: KISS, YAGNI and Occam’s Razor | Effective Software Design
Pingback: Do SOLID design principles make code slow? | Effective Software Design