Software Planning 101 - Part 2/7

The Dimensions of a Software Solution

Now that we know that we need a software solution plan, let’s investigate what it should cover. So given the same software requirements, can we describe how solutions differ? There are so many different decisions to make but each of those decisions can be classified into one of the four dimensions a software plan should cover.

Software Dimensions

For software we need to describe four unique aspects: what logic is executed; how is the code structured; where is the code executed; and what technology is used in the implementation.

Dimension 1: Logic

The execution logic refers to the selection of logic, concrete and abstract forms, to be executed. In abstract form, software is a sequence of steps to perform a specific functionality. In most concrete form, software is a binary containing instructions to be executed by a processing unit. This dimension answers first on a high-level abstraction what the steps are to be performed. After that the details of the concrete form of the software are explicitly added or implied.

If a developer is requested to deliver a solution that can sort a hand of playing cards then the developer has the choice of many different sorting algorithms for implementing the sorting step.

But also on a higher abstraction level we see the same type of decision has to be made. Let’s take the example of having a bar. If we want to sell drinks we need to do two actions: provide the drinks and receive payments. Those can be done in any order but each specific order has different benefits and drawbacks.

When a customer orders drinks and immediately the customer needs to pay, the bar is more likely that no customers walk out without paying for their drinks. But if we change the dynamics and provide the customer with drinks and only make the customer pay at the end of his/her bar visit, the customer could be more likely to order more drinks than compared to being bothered by each time need to make the payment after ordering.

Dimension 2: Structure

The code structure defines how the code of a given execution logic is organized. Each of the statements, that make up the code for the execution logic, has a specific responsibility. Examples are: data validation, data retrieval, parsing, etc... Thus instead if implementing the execution logic as a single list of instructions, it is better to reorganize the code to make sure that a responsibility is not scattered through out all of the software. This allows for ease of altering and extending the software.

Let’s look at code that is responsible for reading a database. Has the software solution, each time it needs to get data from a database, code duplicated to setup the connection? Or is the code regarding the database structured in its own "spot"?

The code structure defines first, on highest level, what responsibility of the software solution is structured into what system. After that more detail is added by splitting each system into components, components into packages, and finally the packages into classes/files. In the end, the code structure determines for all the statements where it needs to be implemented: in what system, component and file.

Dimension 3: Locality

An instruction of the execution logic is executed by a processing unit. In modern computing many processing units are available. For example, a CPU can have multiple cores, and a core can have hyper-threading technology. A machine can have multiple CPUs and many machines exists in the network, divided into different geographic areas, availability zones, racks and tiers or network segments. The execution locality gives answer to where a specific instruction is to be executed.

It is always possible of making a RPC call to another service, with another locality, to execution a statement. Thus two statements that implement a specific execution logic do not automatically have to be on the same processing unit. This shows that both dimensions are independent.

Especially for: performance/scaling, multithreading/concurrent programming, and security (network/tier segmentation), this dimension provides answers that are not covered by the other dimensions.

Dimension 4: Technology

The term implementation technology refers to what technology is used to write/generate, deliver and execute/interpret the execution logic. All other dimensions do not determine any specific technology. Here we make the decision to use MySQL vs MSSQL, or Java vs Ruby.

Conclusion

There are probably more questions to answer and more alternative effective solutions than software engineers used to think about. A software plan should cover the decisions and rational for the four software dimensions: execution logic, code structure, execution locality and implementation technology. Each decision, which is always a trade-off between alternatives, makes sure we eliminate "bad" software solutions - the reason to make a software plan.