Why recreating software by analogy is a doubtful idea

Now, you’ve seen a new feature in an app you use, and you LOVED it! And the next thought is — should add this to my product, it will be AWESOME! Next, you call your IT team and tell them to “add these two buttons here, so that when I press this and then this here, it works like this”. How long can it take anyway, with them having an example in front of them? A couple of days, not more, right?

And then the harsh reality hits hard when they say it will take about a month or more, will cost you several dozen grand, and they don’t even guarantee it will work.

Been there, done that?

But why? In a few words — because the software does not work by analogy, all products are different and recreating something done by someone can be harder than doing it from scratch yourself. Read on to discover the reasons under the hood.

Why making software is really difficult

The main complexity of software engineering is that people can only be experts in one field. Thus said, you can be an excellent salesman, risk analyst, educator, or a financial genius — but you are not likely to also be an expert software developer. You can have a great idea, but you only visualize its external design and the things it should be able to do.

Then the developers start gathering the requirements for your future product’s functionality, and suddenly a million questions you did not mention start to appear. To say more, quite often architecting the software (or even building it already) opens the need for serious adjustments, that go outside the preliminary estimates, and require actually planning from scratch.

There are always accidental and essential complexities in planning software systems. Requirements always change, sometimes quite drastically, so instead of building simple solutions for simple tasks, developers have to build “solution factories” that can be configured to provide different results with relative ease.

In one case, a customer had an AWS cloud instance dedicated to calculating the results from biochemical analysis sent in at appointed time periods from thousands of biolab machinery pieces worldwide. The app dashboard froze when the reports started coming in due to overload. The problem could not be solved by horizontal or vertical scaling — adding more RAM or adding more instances to a cluster did not help.

When the software vendor started analyzing the system, it became apparent that the infrastructure deployed by the client was not adequate for the task. Too few instances were not enough, too many were idling most of the time. Instead, the software engineering team decided to containerize the app, split it into microservices, and invoke the resulting Docker containers atop a Kubernetes cluster.

This way, the system launched exactly as many analytics processes as were needed and shut them down immediately after the end of the analysis. As a result, the app stopped freezing and the AWS infrastructure costs became much more manageable.

Yet another example relates to the period when all banks started rolling out mobile apps for their services. Most banking infrastructure is built on mainframes — platforms that were designed and built long before smartphones became widespread, meaning that such systems can’t easily interact with mobile apps in Java, Python, Kotlin, C++, Objective-C or Swift. Banks had to spend a lot of money and effort to develop middleware able to interpret mobile API requests into signals understandable by mainframe computers.

Long story short, building software is very difficult because:

1. Software engineering still has growth pangs. It is only 70-ish years old and has already gone through a lot of revolutions. We use the same fundamental principles in architecture that ancient Egyptians used to build their pyramids, and we sow the land and cook generally the same as our ancestors did — but everything changes drastically every 5or 10 years in software development. When building any project, any team has to rely on intuition and experimentation as much as on expertise and time-tested best practices. This leads to the next point…
2. Every line of code can lead to a bug. Any function or feature should be accounted for, which is literally impossible. Testing and QA help sort out most bugs, but they cost time and money. Therefore, software released without a single bug is impossible — but the speed and ease of fixing those bugs are essential.
3. User input missing. People who order the software built don’t know how it should work and what challenges will have to be solved to make it useful. Translating user requirements into product specifications with adequate estimates is a complex process that is outside the scope of this article.
4. People don’t know what they want until they see it. When the software development team presents design mockups and clickable prototypes of a future app, customers often realize they don’t need some features and need others instead — which launches the whole process from scratch. Rinse, repeat, until you are satisfied — and only then the real coding can begin.
5. Not all developers are created equal. The software can work using 100 lines of code to perform a function — or it can use 10 lines of code, written by a better developer. Great software engineers are a rare and valuable commodity, and Academy Smart is proud to house quite a few.
6. External dependencies are like laws of nature. They work regardless of whether you know them. There are myriads of dependencies. With other product modules, with open-source components, due to language or framework structure, due to the recent OS and browser patches, and much, much more. These dependencies are updated all the time, so software engineers must build functions that will automatically update the code based on dependencies.
7. Every estimate is a painting, not a blueprint. Developers never know the complexities they will face until they encounter them. Some can be solved on the go, some require making a couple of steps back and rebuilding a module, and some might require changing the architecture of the program. This is why estimates are never definite, neither can they be.

Perhaps now you can see why in-depth research is required to implement even the simplest functions. Let’s now look at how the developers actually estimate the tasks they are given.

Why the interface doesn’t answer the question of how it works

Let’s come back to the situation described in the beginning, when you expect your IT team to reproduce the functionality from another app in your product based on its interface. This case gives only a couple of answers — where the buttons are located, what the UX flow of operations is and what the result is. The questions this does not answer are much more numerous:

• What code is used to execute the function
• Where it runs
• What functions are invoked
• What data is stored in the database and how it is processed
• What challenges were encountered while building this functionality — and how they were solved
• What failover mechanisms are in place
• How analytics on this function are gathered, if any

Some of these questions might be answered based on the developer’s expertise, others are a field of guesswork and require experimental approval of theoretical assumptions.

Let’s take a look at Netflix. As a customer, you select the genres you are interested in, and Netflix offers you new content based on what you have already seen. However, the mathematical model for such recommendations is a “black box testing” case.

Every software feature is built to serve a certain purpose and solve specific tasks for its users — reduce expenses, simplify existing functionality, and improve the existing UI/UX. None of these can be achieved by simply copycatting what others did.

Every new programming language is created to solve problems and inadequacies its predecessors have. Every new framework or other tool is built to automate and simplify code building tasks that would have taken much longer to do manually otherwise.

As a result, there is an endless variety of combinations used in every product, based on the budget allotted during its development, the technology available, and the skills of developers at hand. If something is built and works on one system — there is no guarantee it can be done in exactly the same way in another system, built with other tools and by other people.

Conclusions

Wrapping it up, there are no functional standards for any type of app. Concentrate on what YOUR target audience needs and not what your competitor’s marketing team decided to implement. Only if your users start actually demanding this feature, think of actually adding it — and be prepared to wait for a couple of months at the very least.

Most importantly, trust your IT team. If they say it takes time to experiment — it really does. If they say they will need at least 4 months to develop this feature — they account for a myriad of factors that you can’t even start to expect when looking at a screen with 2 buttons.

This is the approach we follow at Academy Smart. We don’t promise to do it in a couple of days — but we deliver on our promises and build software that drives value for businesses and customers. Get in touch and see for yourself!

Iryna Kurkina

CBO at Academy Smart