The software developers’ way is better!

Let’s get the obvious things out of the way, I’m NOT saying that developers are better than all the rest! What I am saying is that developers (and yes, I’m counting myself as one) are equipped and indoctrinated with a set of tools that allow us to solve problems very effectively — with software. And that these tools take us beyond the act of writing software, into the realm of handling many other challenges that life throws at us. Unfortunately, we sometimes forget it.

To show you how I came to this conclusion, here are the basic assumptions, the “postulates” I’m using:

1. Every (solvable) problem has an algorithm that can solve it!
2. A classical computer can solve any (solvable) problem using an algorithm
3. Every algorithm can be represented as software code
4. Software developers know how to write software

So the fact that developers can solve any problem is extracted directly from the above postulates — since any computer algorithm is a general purpose algorithm, and the software developer is the mechanism that produces it. So the same techniques used for creating software are useful for tackling problems in the “real” world.

So, what does learning to create software have to do with solving problems in the real world? In essence, software is a set of instructions and data to tell a computer what to do. As everyone knows: “A classical computer is an entity that can activate a set of predefined logical discrete instructions useful for solving any problem!” (I copied the last sentence from Wikipedia, so it must be true). But seriously, there is a lot of work around the effectivity of computers to solve a LOT of problems, and let’s face it, everything around you is powered by computers and thus software nowadays. Software is the main tool for solving problems on a vast number of areas, you name it: agriculture, construction, transportation, economics, retail, manufacturing, the list goes on and on. As a matter of fact, there are hardly any areas that don’t use software in some form, and as Marc Andreessen says: “Software is eating the world” — and it’s generally because of its “reach.”

By reach, I mean the extent a tool can be used to do different things. For example, the reach of a car is perfect to take you quickly from place to place, way better than your legs. But it can never take you to the moon, for that you need a tool with a bigger reach, say, a rocket.

Some tools are extremely powerful; they have “universal reach,” usually in a specific domain. For example Writing, and the move from pictograms to the alphabet. The usage of a fixed set of symbols and a specific set of rules on how to combine them allows anyone that knows the rules to convey any message to anyone else that knows these rules. It is also transferable between generations and geographic locations, it has a way bigger reach compared to just shouting. You can say that Writing has a universal reach in the “messaging” domain.

Software is another such a tool. Side note: if you want to understand the subject of reach better, read David Deutsch’s book, The Beginning of Infinity, in which he coins the phrase “universal reach”, to the best of my knowledge.

In order to achieve a working piece of software, developers are trained as generic problem solvers in real-world scenarios. We write algorithms using code, but what we actually do is solve business problems using software, and since software has universal reach, it can be utilized to any problem domain, including the “real life.”

You see, a software program does not lie, it either solves the problem or it does not. When it does not solve the problem it would fail in many ways. Sometimes spectacularly as crashing the entire process or even the operating system. Sometimes subtly, like working a million times correctly and failing once in a million. Or it might solve most of the problem but not quite, and fail on edge cases, or it might be logically sound but work very, very, very, very slowly…

There are infinitely more ways to get a program wrong, than getting it right. A running software is relentless, it will not budge. It will always tell you the truth. You can not talk or trick your way out of a software bug, the software has to be logically (and technically) sound so that it generates the outputs you need.

“Computers are like Old Testament gods; lots of rules and no mercy…” — Joseph Campbell

So in order to tackle this challenge, a developer is equipped with an abstract “magic” toolkit she uses for solving any given problem.

A few of these magic tools I refer to are:

• Algorithms — the logical recipe for solving a problem.
• Design principles and patterns — using modularity and abstractions in solving the problem.
• Data structures — how to represent data.
• Architectures — handling complex systems, their interconnectedness, and complexity.
• Agile methodologies — how to create the right product by using fast small cycles and get it to market.
• Testing and monitoring — how to protect yourself from mistakes and making sure you are still doing the right things.

I’m not talking about learning to code per se, nor about the actual act of writing software. It’s more about being logical in your approach to the problem, and using the tools for getting a software project working. It’s about analyzing it and bringing the solution to fruition, and then following up and making sure it keeps on working. The design, architecture, and software management methodologies, should be the cornerstone of how to approach solving a problem.

I’ll try to make it more concrete. Let me share a personal challenge.

In the last year, my wife got sick, breast cancer (deep, long breath). Side note: go get checked, it saved my wife’s life and my kids have a mother.

When this hurricane came, we were of course unprepared. You really can’t prepare for that. We were thrown into a new and scary world, and although the people around us and the system really wanted to help, it was overwhelming. This was in no way similar to software projects, but we actually used some of the tools I mentioned above. The first thing we did was research; we wanted to know the basics so we could ask the right questions. Next, we had to make some decisions as to the right treatments, and we had to find them (which was not obvious at all). Funnily enough, doctors do not tell you what to do, they just advise, and in our case, there were four different disciplines for treating our situation. We had to make many decisions along the way. Since my wife is also a software professional, we intuitively sliced the problem to different areas, kind of modularizing the problem so we could prioritize and focus on more pressing problems first (agile). We did not define an MVP (though the term Minimal Viable Product, gets kind of a different meaning in this context). But, it allowed us to focus and defer some decisions to later. Along the way, we tested our assumptions and cross-validated (second opinions and other sources), we asked a lot of questions and tried to get consistent responses from different people in the process (testing and monitoring).

True, it’s odd to look back on such events and think of them as software projects. Mainly because they seem way less structured, and with much more opacity to them (we knew close to nothing about treating breast cancer beforehand). But reflecting on my experiences of software projects I found that many times they are like walking in the fog, inside a thick tropical jungle, in a pitch black moonless night, during a storm, looking for a black cat! Every once in a while you get into a clearing and as the lightning strikes, you get some clues as to where you need to go next. So the tools I mention also evolved to handle this unpredictability.

In our private lives, it’s pretty much the same, we want to do things, buy things, go on a trip, earn money, get well and such. In each one of these situations, we could utilize some of the tools I’m talking about. After all, they evolved to handle the chaotic unpredictability of doing $#!7.

You must be wondering how come I’m praising developers so much, and you actually know these guys — some of them are dry and fixated, seem very technical and uncreative (if there is such a word?). So yes, I’ll stand behind the developers’ way, but people are people. What I found out is that while the developers approach to problem-solving works best for almost everything, it does not mean that we use it in every situation. There is the problem of domain context. Or in less fancy words, the ability to take a useful solution or behavior in one field and use it in another. And developers are (mainly) human — while sometimes we can work magic on any logical problem, other times we fail completely with business problems or personal problems.

But I strongly suggest putting on your developers’ hat when real life happens!