Photo by Robert Hrovat on Unsplash
Several years ago, in a post on Quora, I wrote that the only thing I feared as a software engineer was running out of money.
It was an odd realization on my part, and it has been the central guiding principle of my approach to software architecture.
So, I think it’s worth expanding on why I feel that way and how I use it to drive decision-making. At NetApp and Zynga, I had seen how financial decisions killed technology. I spent four years of my life working on a product called the net cash. The last thing I built was a multithreaded system that offered unique safety properties. It was the most intellectually satisfying thing I ever made. And it sits in a code repository collecting dust. Here’s the patent https://patents.justia.com/patent/7373640 for those that care.
At Zynga, I watched how a brilliant team that had built up a brilliant set of tools for operationalizing private and public clouds got destroyed in the space of four months because we couldn’t pay the bills.
My one personal regret is that I did not appreciate how much value there was in offering servers on demand.
What the experience taught me is that unless you are making money every quarter, you are going out of business. Any plan has to be making money now, or the organization will get destroyed.
So? I take a very pragmatic you towards software architecture. There are two critical questions.
1. What is the right answer to the problem?
As computer science is a science, we can reason about correctness. For a given problem and a given a set of constraints on computation and a bunch of desired outcomes, it is possible to articulate a correct answer that is independent of staffing or resourcing or timelines. Without knowledge of the right answer, it is impossible to know whether the problem has a solution.
So what?
Without the knowledge of a correct answer, it is elementary to spend a lot of time building wrong things. I am not talking about technical debt, but something so wrong that the only path forward is a complete and utter rewrite.
Let me give an example. Suppose you have a system where two entities must synchronize before the system converges to correct behavior. If the system assumed a human operator would observe and take action if the convergence doesn’t happen, and you wanted it to work without a human being, you need a new system.
Another example I like to use is the fallacy that it is possible to build a distributed system from a monolithic system by just adding RPC’s. The reality is that because of how RPC’s are different from a function call in a shared memory address. This approach doesn’t work. When failure modes get introduced in new places or timings of functions change, the system starts to break in all sorts of wonderfully wondrous ways. In my career, I have had to stop four different projects at four companies where this was the proposed direction.
Understanding whether the problem you’re trying to solve has a correct answer and that the proposal you’re making is correct is a critical element to any architecture.
In many ways, software architecture is proof of overall system correctness. For those who are knowledgeable in the field and understand the system well, it is possible to understand by reading the architecture spec whether the system is or is not correct.
So this brings me to the second important question.
2. What is the right answer, right now?
Money is what pays the bills. Often, I have found myself in debates over “the long-term answer” versus the “short term answer.” On the one hand are architects who are upset that we aren’t taking shortcuts to build the correct answer. On the other hand, some are frustrated that there is the immediate business value that could be derived if we were willing to make some sensible shortcuts.
I believe that any architecture that cannot deliver value right now is of no value. But wait, I hear you say you can’t deliver something in six months if it takes two years to build. True. But if you know what the long-term answer is, you can make better short-term trade-offs that move you along the long-term trajectory.
In effect, I believe that knowing what the correct answer is, allows you to evaluate whether the trade-offs of the short term answer are worth it.
Furthermore, understanding what the correct answer is, allows you to look at a short term answer and determine what set of use cases it will work for and what set of use cases it will not.
Finally, that understanding allows you to determine the business value of the short term answer. For example, if the short term answer is for 70% of the use cases, and that represents 97% of the revenue, then it may be okay. However, if it addresses 97% of the revenue that is shrinking rapidly and 0% of the revenue that is exploding, it may be a waste of time.
In conclusion, the notion that there is a trade-off between the long-term and the short-term is a fallacy. The long-term is always changing, and the short-term is what pays the bills, and software is a very malleable substance. Understanding the long-term allows you to make the right trade-offs in the short term such that the correct long-term answer is always within reach and that every step of the way, the exchanges are being made explicitly and not blindly. And software can always be changed. The question is how much.
Leave a Reply