What are the common breakdowns in a software-making machine ?
In the previous blog, we looked at how a software-making machine works. Meaning, how a software company functions. (https://techwiddeep.com/software-producing-machine/)
Continuing the discussion, we look at the common problems at a software company. In other words, common problems within a software-making machine.
The first spot goes to the most obvious one …
Poor parts
A machine can have poor parts. In our context, these will be:
They might not know how to give requirements. Or worse, might not know what they want 😳😳. Believe it or not – It’s more common than you’d imagine.
Might be unable to translate business requirements to tech ones or vice versa.
Do not know technology or not at the required skill level.
Might not know how to manage, delegate, prioritize, coordinate, etc
Might know how to test functionality.
or … ALL the above. In which case the faulty part is …
His job is to tune and replace the machine parts viz. techies, managers. But, he might not
have the skills to recognize and fix faulty parts. And again it’s more common than you’d
think. 😑😑
Out-of-tune or faulty parts is a common problem in software machines.
Friction
While energy is neither created nor destroyed, it is gained and lost.
When two parts of a machine that do not coordinate with each other lose energy. Within a software development machine, the loss looks like …
Friction loses effort. To me, this point is easily understood by most people. For this reason, I will not elaborate on it.
Onto the next issue type …
Malleable
Softwares are malleable (able to change shape without breaking).
On one hand, malleability is a strength for the software itself. On the other, this is a challenge for the software-producing machine.
Let’s elaborate:
This means each employee joining the company will have to first understand the conventions. And only then start being productive.
Also, most companies have poor onboarding practices.
Combining both points:
Poor onboarding practices PLUS different names
EQUALS
Engineers joining teams and architecture, they do not understand.
A great employee joins a team. Does he understand the local nomenclature ?
In most cases, the answer is NO.
Result – Most employees struggle to be productive. I did !
On one hand, the ability to custom-name environments is an advantage. On the other, it hampers scalability across the industry.
Lack of standard nomenclature is a decelerating factor in the software development machine.
Similarly, two product-based software companies are not the same.
While such malleability is welcome. It creates a situation where each part (employee) needs to first acclimatize to its environment. And only then, become productive.
The malleability of software creates an easily changeable environment. Such an environment needs the machine to spend time adjusting to its environment. And of course, producing code
No surprise that – ever-changing software machines are slow.
Subjective Input Objective Output
Heads up ! this idea will be tricky to understand. While so, it will also be a valuable insight into how a software machine works. Also, this section is why my blogs are worth reading.
Subjective Input
Let’s look at the input to the software developing machine – requirements. We know that requirements are words, and words are subjective. By derivation – # input to a software machine is SUBJECTIVE.
Even when well documented, words are easy to be “interpreted” per one’s bias/ convenience.
Also, words, by their nature, are momentary. To prove that, let me ask you a question.
How many conversations do you remember, from today, “word for word” ?
Very few you say ! Exactly my point.
Capturing all the nuances of every requirement with all cases is a difficult job. As a writer, I can tell you that putting ideas into words is in itself a difficult task. Doing so at an organization’s scale is a next-level task.
Objective Output
While the input of a software machine is subjective, the output is objective. This is because clients expect software to work in a certain manner.
Combining the two points(#) we have a machine with a subjective input and objective output. Inherently at odds, these create perfect conditions for messing up development work.
The contrary nature of input/ output creates issues like …
Evolution designed humans for audio/ visual cues, and NOT words. ( I realize the irony with the length of my blog here 😀😀 ). Even so, words are the input to our software development machine. Meaning, humans face a disadvantage in using words to produce code. i.e. using subjective input to create an objective output.
Organizations aware of this paradox put quality checks into their requirements gathering process. The others find issues much later, with high repair costs.
f
This is another common reason for issues in software development machines.
Activity time : Try and recall the first few lines of this blog. ( do not scroll back )
Seriously, Do it !
Most of us will be unable to do so. Goes to prove the momentary nature of words.
Do you see how easily requirements can be missed ?
Moving on …
Nature of the ware
The virtual nature of software makes it difficult to reach the root cause of software issues.
To understand this statement, help me answer these questions …
( for your sake ) I hope you weren’t able to answer any of the above questions. Obviously, the next question is:
This question is the starting point of our discussion.
A wine, a dish, a piece of marble, a car, an egg, and other things that exist in the real world. We also know that software exists in the virtual world ( inside a computer )
None of the 5 human senses – touch, smell, see, taste, and hear, help us look inside a computer. So, we are put at an immediate disadvantage while evaluating software programs.
While most of us will agree with the above idea, few will “really” understand it. So, allow me an example:
A Virtual World
Seen the movie Inception, Matrix, or Free Guy ?
The movies depict a virtual world, with some rules. While few rules were unchangeable, but most were changeable. Also, these rules were created by an architect.
## In the movie ‘The Matrix’, imagine a city where everyone owns a Bus and NOT a car/ bike. Let’s imagine a typical morning:
Would a normal road infrastructure support such traffic ? HELL NO !
The result would be traffic jams and blockages. This is what happens within the software and is called a performance issue.
In our context – this is a poor quality output from the software development machine.
In the real world, people would quickly see the shortcomings of road infrastructure. Someone would object very soon. By comparison, hardly anyone would object to the design within a program.
and Why ?
Because, looking inside a virtual world requires skills, experience, time, and energy. In other words, because it’s difficult.
While real-world has bound rules and tangible results, virtual one has very few rules. More importantly, a VIRTUAL END PRODUCT.
The virtual nature of software makes it difficult to reach the root cause of software issues.
Expensive debugging is another common issue in the software-creating machine.
Wrap up
We can look at a software company like any other machine, like a car. Once we do, we will realize that, like a car, a software company can …
And just like Ferrari, high-quality software requires many things:
Only when all factors work together, the software machine delivers Ferrari code.
Thanks to Ray Dalio for helping me see a ‘Software development company’ as a machine. ( from his book Principles )
Write back, in case you have an opinion. Like what you read – do like, comment and share.