The Difference Between Building Software and Solving a Problem
There is an important difference between building software and solving a problem.
They are related.
But they are not the same thing.
A developer can successfully build an application and still fail to solve the organization's problem.
This is one of the most important lessons I have learned from working on real-world systems.
The Code Can Be Perfect and the System Can Still Fail
Imagine a hospital asks for a new digital system.
The development team builds it.
The interface looks modern.
The application is fast.
The database is well structured.
The APIs work.
The deployment is successful.
Technically, everything looks good.
But then users don't use it.
Why?
Perhaps the workflow doesn't match how the hospital actually operates.
Perhaps information has to be entered multiple times.
Perhaps users need information at a different point in the process.
Perhaps the system doesn't handle an important exception.
Perhaps the network environment was ignored.
Perhaps training wasn't considered.
Perhaps the system solved the developer's understanding of the problem rather than the user's actual problem.
This is why software engineering is more than programming.
Start With the Workflow
Before designing a system, I want to understand the workflow.
For example:
Who starts the process?
What information is created?
Where does that information go?
Who uses it next?
What decisions depend on it?
What happens when something goes wrong?
What information does management need later?
These questions can reveal problems that are invisible when looking only at a list of software features.
Features Are Not the Same as Solutions
A requirements document might say:
Patient registration
Payment
Pharmacy
Reports
User management
Dashboard
But those are features.
They do not automatically describe the real problem.
The real problem might be:
Patient information is being entered multiple times.
Or:
Financial transactions cannot easily be reconciled.
Or:
Pharmacy stock information is not available to management.
Or:
Insurance information is disconnected from service delivery.
Those are operational problems.
The software features should exist because they solve those problems.
Healthcare Makes This Even More Important
Healthcare systems are particularly sensitive to workflow design.
A small design decision can affect:
patient registration
clinical documentation
payment
insurance
pharmacy
laboratory
reporting
management decisions
This means a developer working in healthcare needs to think beyond code.
You need to understand the people using the system.
You need to understand the process.
You need to understand the data.
You need to understand the organization's objectives.
And you need to understand the environment in which the software will operate.
Local Context Matters
Building software in Ethiopia also comes with its own realities.
Internet connectivity can vary.
Hardware environments differ.
Organizations have different levels of digital maturity.
Users have different technical backgrounds.
Government reporting requirements matter.
Local business processes matter.
Language and localization matter.
Infrastructure matters.
A solution that works perfectly in one environment may need significant adaptation in another.
This is why I believe local software development should not simply copy solutions from elsewhere.
We should learn from global technology while designing for local realities.
What I Try to Build
When I approach a project, I try to think in this order:
1. Problem
What is actually going wrong?
2. People
Who experiences the problem?
3. Workflow
How does the organization currently operate?
4. Data
What information is created, changed, and consumed?
5. Solution
What should the digital system actually do?
6. Technology
Which architecture and technologies are appropriate?
7. Deployment
How will the system work in the real environment?
8. Improvement
What do users teach us after deployment?
This approach changes the role of the developer.
You are no longer simply receiving requirements and writing code.
You become part of the problem-solving process.
The Developer's Real Responsibility
I believe a strong software engineer should be able to ask:
Why?
Not only:
What feature do you want?
If someone asks for a dashboard, ask:
What decision will the dashboard help you make?
If someone asks for a report, ask:
What problem will the report help you solve?
If someone asks for automation, ask:
What manual process are we trying to improve?
Those questions often lead to better systems.
My Approach Going Forward
My goal is to continue building systems that solve practical problems in healthcare and business.
I also want to document what I learn.
The technologies will continue to change.
Frameworks will change.
Programming languages will change.
AI will change how we build software.
But one thing will remain:
Organizations will still have problems that need to be understood and solved.
That is where I want my work to remain focused.
Not technology for technology's sake.
But:
Problem → Understanding → System → Deployment → Impact.
That is the kind of engineering I want to practice.
— Haji Omer Sheno