CTO ROUNDTABLE #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!).
We like people, so feel free to call or write. Humans only.
