One of the most problematic practices in engineering organizations that I have joined is the rejection of complex solutions to complex problems because they are difficult.
Any problem at a large scale of customers is complex. The software has to deal with a comprehensive and unknowable set of use-cases and deployments. The software has to cater to a large number of other systems and users that interact with it.
Any change to the system can have unknowable impacts.
Suppose we have a piece of software, let’s say Acme Management Center (AM Center), and we need to make a significant architectural shift.
For example, if you need to change a system from:
- being single-threaded to multi-threaded;
- being a single point of failure to tolerate multiple-failures;
- using a single database, and using multiple federated databases;
- being a closed a system being open;
the size of the effort depends on the complexity of the software being change.
If AMC has a small number of users or is small, the cost of the change is tiny.
If the system, let’s call it BigVirtuCo Center (BVCC), has many users and has been around for 20 years, the effort to make the identical architectural change is enormous.
We intuitively understand the complexity of the two efforts as being different.
But then let’s turn it around a little bit. Why was the change of BVC Center’s architecture so much harder than AM Center? It’s because BVC Center supports 20 years’ worth of unique features more than AM Center.
Now BVC Center is worth 10 billion dollars because of how many people use it. AM Center is worth 1 million dollars because of the number of people who use it.
AM Center is a delicate product, but it simply doesn’t have the feature set that BVC Center has and thus can’t solve the problem that BVC Center solves.
A typical fallacy that the BVC Center competitors engage in is to say, “well, we can make something that has 80% of the value of BVC Center and kill it in 1/10 the time by focusing on 20% of the features”.
They are saying that there is a more straightforward solution to the complex problem that BVC Center solved.
And the competitors of BVC Center typically fail.
Oh, but what about the innovator’s dilemma?
Simpler products can indeed displace BVC Center. But they don’t replace BVC Center when they are simple; what happens is that they find a big complex problem that BVC Center ignored and become entrenched in that space.
BVC Center doesn’t get displaced by a simpler product; it gets displaced by a complex product solving a complex problem of higher value than the one BVC Center solved. Most of the time, the thing replacing BVC Center is more complicated than BVC Center ever was.
The problem with complex problems is that they take a lot of time and resources to solve.
As a software architect, it’s essential to understand what the correct solution to the problem is. And to not shy away from the complexity.
At the same time, we need to ship software. And this brings us to the tricky problem: not the discovery of the correct solution but the delineation of an approximation that adds value and moves you in the direction of solving the problem.
For example, making a program multi-threaded that had a single thread is a massive undertaking. Incrementally adding threads and parallelizing pieces of the system allows you to take advantage of more processing power.
Similarly, a customer may have a complex problem that will take years to solve. The customer is willing to live with a partial solution if that leads to a complete solution.
To revisit the beginning of this thread, frequently, folks say – “this is too complex.” And perhaps it is. Or perhaps what they are saying is that the cost of the solution is too high.
As an engineer, it’s essential to understand what the correct answer is, and at the same time, what is the slice of the right solution that we need to do today and never to confuse the cut as the correct answer.
Leave a Reply