cto-3

We’ve all had to face “tech monsters” from time to time. The most recent CTO RoundTable talked about one of the secret methods that BitWise uses to solve seemingly impossible problems!

If there really isn’t enough information to make a headway in troubleshooting, there should be an alternative way to obtain said information. For example, if an application doesn’t load, it can be run outside of the web server in a debug mode. Or, let’s say you have three components —  Apache, Laravel, and  SQL server — and your error message is about Laravel: what is the effectiveness of troubleshooting Apache? This is an example of no relationship – but what if there is? 

Sometimes we discover these tech monsters when we jump into projects that were started by others a long time ago. We may be tasked with building effective, smart ecosystems by transforming from legacy from across retail, automotive, utilities, etc.  That’s a monster across industries! To dissect a big tech monster, you want to cut it into smaller pieces. By defining the subject of enquiry precisely, it becomes obvious that thing can be tested separately. > THE SYSTEM IS A DIVISIBLE MONSTER!

“Facts” of course depend on your point of observation. Remember the analogy of the elephant where each ant describes it based upon where he is perched on the elephant — and of course the descriptions are completely different. Patience, and the willingness to suspend judgment instead of blindly pursuing a path of enquiry, are required in dissecting tech monsters.

Everything is divisible, and our ability to divide something depends on our definition of whole/parts. It’s important to remember that this doesn’t have to be “The Final Truth” from the get go. It may actually never become “final”. It’s just a “working” definition. 

 In fact, the “dissection” can be described in three parts (Remember your tech monster!):

1) Awareness, observation, and non-judgement – Be like Spock!

The first thing that a scientist needs to learn is attention to detail. At any given moment there are many pieces of information around us that require explanation. We coach many beginning programmers, and I always tell them that this is one thing that we can’t teach – attention to detail. It requires practice, and mindfulness. 

Observation is there to determine identity. If you can’t differentiate, then you’re not getting into enough detail. You can do this by changing your point of view and also by applying a variety of observational techniques. The goal is to clearly identify whatever it is we’re observing.

For example, when you have a server that is being “slow”, and you’re trying to determine what is causing that. Let’s say, all you have is this “load” measurement which is a combination of CPU, disk and memory. Obviously it will be high when the server is slow, but it’s not helping you to solve the problem (because you haven’t identified those three parameters separately). So, this “load” measurement is useless for this purpose and doesn’t count as an observation.

2) Practical usage of categories – Define your subject of inquiry.

Next we need to categorize our observations. In order to do that, we have to create categories first. Then we can decide which category a given fact belongs to. Kind of like sorting laundry.

Proper categorization enhances our understanding of the situation sufficiently to come up with a possible explanation for the problem that we’re trying to solve.

We can start hypothesizing. It doesn’t have to be a full blown prediction, but it should be something that is observable and measurable. For example, you’re setting up a CGI application. You configured everything, but it comes up blank. What next? Simply run the application outside of the web-server to observe what happens. If you get an error, great, if not, you must have missed something in your CGI setup.

3) Resourcefulness – Find new ways to observe your subject.

What happens if there’s no way of getting your CPU memory and disc measurements separately? What if there are several “candidate” causes? Can you isolate the influence of a certain factor? What if the problem can only be observed in production? What happens if the measurements you need aren’t available? You need to be resourceful in designing of your experiments and look for different ways to measure the effect. (We’re not going to give you a “spoonful of McGyver” – systematically approach the contradictions and work with what you have to find a solution).

These three parts are actually key tenets of the scientific method, which was developed over the course of several hundred years. It surprises some people to learn that science is not about finding “the answer”. It’s a method to continue learning more about the subject of enquiry (in our case, tech monsters!) 

It was Aristotle back around 350 BCE who gave us the logic of classes, or categories — statements that can be represented in terms of classes of things, and relationships between those classes.

For example, the categorical statement “All cows are mammals” would be represented as a relation between the class of cows and the class of mammals (namely, that the class of cows is a subset of the class of mammals, or equivalently, that all members of the class of cows are also members of the class of mammals).

A categorical syllogism is an argument consisting of exactly three categorical statements (two premises and a conclusion) in which there appear a total of exactly three categorical terms, each of which is used exactly twice.

Examples:

Premise 1. All humans are mammals.

Premise 2. Some builders are human.

Conclusion: Some mammals are builders.

Premise 1. No geese are felines.
Premise 2. Some birds are geese.
Conclusion: Some birds are not felines.

Aristotle examined all the logically distinct types of syllogisms that could be created using the basic categorical statements, and identified which are deductively valid and which are invalid. (There are fourteen valid forms in Aristotle’s system. Medieval logicians gave them all names.)

But the scientific method is not as well known as it should be. Greater understanding of it, will help you dissect your tech monsters. How do you formulate a hypotheses, how do you test it and evaluate the result?

The answer key lies in understanding causation and those syllogisms – it’s basic if p then q, root-cause analysis. If you don’t have empirical evidence to support your claims then you are just guessing. And that’s what makes facing those tech monsters so hard! So, intuitively we manage. We hope for the best and stab in the dark.

Databases however,  cannot distinguish between subject and object – that’s the inefficiency of an algorithm.

Here’s a timeline of scientists who further developed logic and thus scientific enquiry, and it’s fun to read about them and how their work contributed toward our contemporary understanding of how knowledge is created, and how problems can be solved:

Copernicus – 1473 – 1543 

Petrus Ramus – 1515–1572

Galileo – 1564 – 1642

John Locke – 1632 – 1704

Newton – 1642 – 1726

Leibniz – 1646 – 1716

DeMorgan 1806 – 1871

Boole – 1815 – 1864

Gottlob Frege – 1848 – 1925

And somewhere along the way, we took a turn away from good old Artistole and his syllogisms. We veered away from deductive reasoning to inductive reasoning. We blame Bertrand Russell for this turn in thinking. We stopped looking at categories and rushed headlong into statistics. We confused numerical evidence with numerical methods.

So then … when do you have enough information to propose a solution? 

These days, few people can build syllogisms — but it’s the only way you can know. From medieval logic to modern logic, we have lost the ability to analyze. So if you want to dissect a tech monster, try exploring a little logic and the scientific method. Or, you can just call BitWise!