How to Explain Source Code to Business Stakeholders?

Key Takeaways

• It’s important to educate the business stakeholders about the source code the software developers write!
• High level knowledge of the source code blocks help business analysts, project managers and product owners to estimate the requirements / features better, plan more realistic deadlines and mitigate risks.
• Business logic is the core source code that is solving the business problem (Business Logic Code)
• The software developer needs to write extra code to handle the lifecycle of the software (Lifecycle Code).
• The software developer should write code to connect to other services or systems (Networking Code).
• The software developer needs to write code to translate or transform the exchanged messages with other applications (Binding Code).
• The software developer needs to write code to persist data to a database or files. Deal with the cache and many other aspects of the application state (State Management Code)

Analogy

Let’s start with the following question: “What are the parts that compose a bike?” The answer could be: Frame, wheels, saddle, brakes… (for a complete list you can read more here) We can think about the bike as kind-of a system that solve a problem for us. Transportation! We use the bike to move from point A to point B. That is a value.

The same way, we need software programs to solve our problems. In business, the software is developed to automate repetitive tasks, support our decisions, predict the future…etc. In general, we need this software either to maximize the revenue or to reduce the costs.

A software application is a complex system (could be also complicated! ) that is built up of many components. We can group these components or parts in many ways:

• Group by the technical functions or architecture: Web service, API, client, database, cache service, front-end, back-end, agent, message bus…etc.
• Group by the physical components: Web server, proxy server, database server, storage server, Firewall…etc.
• Group by the source code Itself: I find it personally very interesting to educate business stakeholders or clients about the source code the software developers write!

Any software application is a set of instructions written in human-readable language (called source code ) that will be translated into 0s & 1s the CPU understands very well!

In the past, the source code was less complicated even smaller. Nowadays, when we talk about a software application, It includes way many components that are distributed (deployed) on multiple hosts: on-premise (data center servers and virtual machine), cloud providers (Microsoft Azure, Amazon AWS, Google cloud…) or in containers (Dockers, Kubernetes…). Let’s go back to the source code and try to group its parts from the software developer perspective!

5 Blocks Of The Application Source Code

In the modern software world, most of the business or enterprise applications are described as distributed systems. It’s a complex software where some parts are hosted on-premise while others parts or services are hosted in containers or in the cloud. Any distributed system should have the following blocks in its source code:

1. Business Logic Code

This part of the source code is the core value for the business. It’s an algorithm that solve the business problem. Let’s take a real world example. A factory manager used to schedule the workers’ shifts manually. It worked like this in the past. However, such a task will become very frustrating for a human when we have 100 workers who should be assigned for 3-shifts working day! Even worse, What if the law prevents the worker to do 2 consecutive shifts!

This is a known mathematical problem called the Nurse Scheduling Problem. It can be programmed and we can find an “optimal” solution satisfying all the constrains. The source code that do the scheduling is the business logic of the application.

Unfortunately the life is not that easy! We need a list of workers, list of shifts, rules and constrains to comply with the labor law, save the schedule and make it accessible to everyone, allow the workers to see their shifts, allow the shift manager to change the schedule if someone is sick or on holiday… We can imagine an endless list of requirements that the software developer should keep in mind!

2. Lifecycle Code

In order to bring our business logic to life, we need to convert the code to an running program. the whole process of creating a running application is called application lifecycle management.

Application lifecycle management (ALM) is the people, tools, and processes that manage the life cycle of an application from conception to end of life. (RedHat)

The software developer needs to write extra source code to handle the lifecycle of the software. This includes: code to create a deployment package, test the business logic, run the application on the server, check the health of the whole system…etc.

3. Networking Code

Let’s go back to the scheduling problem, to continue the automation, we need to connect the new program to the HR and finance departments. so that we calculate the worker salary based on the shifts (s)he did and transfer the money to the bank account automatically.

In order to do that, the software developer should write code to connect to other services or systems. Not only that, we need to know where are these services located? What to do if they are not reachable? Is there any security issues (especially when dealing with money transfer)? Should we keep a log of the communication history?…

4. Binding Code

Binding code deal with more the technical details of communications with other system. There are many programming languages (Python, Go, C#, C++, Java…) and many communications protocols and messages formats (HTTP, TCP, gRPC, RPC, XML, JSON…)

Not all software system are designed and developed the same way. Let’s go back to the factory example to make the point clear. It could be that the scheduling system is using HTTP/JSON. However, The HR system is using another communication protocol or format (RPC/XML). Therefore, the software developer needs to write code to translate or transform the exchanged messages with other application in order to achieve the business goal.

5. State & State Management Code

State and state management are the most difficult concepts to explain! It’s even hard to explain them to software developers 😜

Anyway, I will try to explain them my way:

State: The state of application represents all user input data (when we fill a web form) and all variable in the source code, all data in the database and file system, all configurations…etc. It’s actually the behavior of the system at a given moment in time. If you like mathematics, a software state is actually an application of Finite-State Machine

State Management: Is the code a developer writes to manage and handle the application state! Some examples are:

• Code to read data from and write data to the database or the file system.
• Code to cache data.
• Code to manage the information flow within the system.
• Code to exchange the data between the back-end services and the front-end (UI) code.
• Application architecture & programming paradigms
• and much more!

There is no universal solution to any individual behavior listed above. And that’s a good thing, because if such a solution existed, software developers will have to deliver pizza 🍕 🍕 🍕

The point is that state & state management have no clear definition and the day they have (AI and No code are good potentials), we developers may become jobless! At least I’m claiming this

Soulaiman Ghanem on LinkedIn: #softwareengineering #AI #nocode

Conclusion

It’s very important that business stockholders look at the problem and the solution from the software developers perspective as well as the business perspective. It will help business analysts, project managers and product owners to estimate the business requirements better, plan more realistic deadlines and mitigate risks.

On the other hand, Good software developers (not coders) know how to organize the 5 mentioned blocks in a way that implementing new changes (features) will be easier and less risky! Otherwise, we fall into a technical debt.

SOLID principles, Domain Driven Design, 12-Factor App and Microservices patterns are some examples of software engineering best practices.

Last word: The next time you tell the developer “It’s a 5 minutes change!”, remember that code is not only business logic. There are other 4 guys (Lifecycle, networking, binding and state) have to be changed or more precisely refactored.