What If Investment Bankers Were Software Architects

Increasing the value

To achieve this, we can design the system in a way that the number of business features can grow faster than the cost of creating them.

How can this be achieved? In many ways. Here are some of them:

• Reusing data and platform for multiple business purposes (example: one platform with one collection of data used by multiple business projects).
• Making the system scalable from the business feature perspective so that, for example, it is very easy to add more features by simple configuration etc.
• Making software flexible. In order to do that you need to have a deep understanding of how it is used so you know what is likely to change in the future. Once you have it you make these pieces as configurable as can be.

Decreasing the cost

We can decrease the cost while keeping the same value for users.

How can that be achieved? In many ways. Here are some of them:

Cleanup

Usually, people do not like cleanups because they are:

• Risky (it is usually difficult to be sure nobody is using it; if there are still some forgotten users, it will cause a problem)
• Low appreciation (if you decommission a system, they say “thanks”; if you introduce a new one, you get promoted, although the first option is better for maximizing the assets to liabilities ratio)
• They simply forget (it is never urgent; you can always do it, so it never gets done).

Nassim Nicholas Taleb (#nassimtaleb) was often referring to Via Negativa. In case you are not familiar with it: it focuses on removing rather than on adding, so it is a “if you are gaining weight do not start taking pills but remove carbs from your diet” kind of thinking.

This is a great perspective for looking at software if we have already identified the costs.

You can remove many future issues before they happen by:

• Removing dependencies (people add them because they need them, but they do not remove them when they no longer need them)
• Decommissioning whole projects (the TCO goes down, the team is happy because instead of maintaining it can focus on creative things, faster onboarding of new joiners, etc.).

Simplify

I am sure you have heard about it many times. I would say software architects agree with it in theory but not in practice. They still come up with complex, fancy designs and I would risk the statement that: Complexity is the biggest problem for software engineering.

If we go a bit further: if a system is designed to be simple it may succeed or not, but if it is designed in a complex way, it will certainly fail.

Self-maintaining system

Try to design the system in a way that does not require people to run it. If something has failed, got stuck, or requires restarting, it should be done automatically by some resubmission logic etc. If something fails because of an external system/team – your software can take action that normally would be done by humans; for example, raising a ticket for some team, sending email, etc.

Do not leave space for human intervention.

Of course, there will be cases like a coding bug or race condition that will require the dev team to take a look, but only these cases should require people. Any non-creative work should be done by software.

Tests

Where are the automated tests on the asset and liability perspective? That depends. If the tests are testing the contract that changes very rarely and guarantee the quality, then they certainly belong to assets. If the tests are tightly coupled with technical details of the solution and require frequent changes, meaning the cost of their maintenance is high, then they belong to liabilities. Obviously flaky tests (ones that may have different outcomes for the same input) are liabilities.

Summary

If each module or line of code is a liability and removing them is good, I am not suggesting cutting any corners by putting everything into one module or compressing code, etc. It is important to understand that each technical entity is justified only if it delivers value for the users.

If we cannot find any, I would suggest removing it.

As they say, “A good developer writes code, a great developer removes it.”