Technology has changed enormously during my career.
Programming languages evolved.
Frameworks appeared and disappeared.
Development methodologies changed.
Artificial Intelligence is now changing software development once again.
Yet looking back, I have come to believe that two principles have remained remarkably constant.
Neither of them has anything to do with technology.
Lesson 1 — Understand WHY
"Just tell me what to build. I don't need to know why."
I heard that sentence more than once during my career.
I never liked it.
Not because every software developer has to become a domain expert.
But because good software rarely starts with source code.
It starts with understanding.
Specifications are never complete.
That is not a criticism of analysts.
It is simply reality.
No document can capture every operational detail, every exception or every piece of practical experience that exists inside an organisation.
Agile development has improved communication enormously.
Developers, analysts and users now work together much more closely than they did thirty years ago.
Yet one fundamental truth has not changed.
Specifications will always be incomplete.
Not because people do a poor job writing them.
But because knowledge is distributed.
Some knowledge exists in documentation.
Some exists in operational experience.
Some only becomes visible while building the solution.
Users also tend to describe new functionality in terms of what they already know. Existing systems naturally become the reference point, making it difficult to imagine possibilities beyond today's solution.
That is exactly why software development should be a dialogue rather than a translation exercise.
A specification tells you what needs to be built.
Understanding the domain helps you discover why.
The moment a developer loses interest in why something has to be built and focuses only on what needs to be coded, the first handicap has already appeared.
Lesson 2 — Preserve WHY
Only recently I experienced why this matters.
A design decision I had made almost ten years earlier suddenly became the subject of discussion again.
Not because the software had failed.
Not because the architecture had been wrong.
But because the reasoning behind that decision had gradually disappeared from the organisation.
The software still contained the decision.
The WHY behind that decision had faded away.
That experience made me realise something important.
Knowledge management is not simply about preserving documentation.
It is about preserving understanding.
It is about ensuring that future developers, architects and organisations still understand why important decisions were made.
Knowledge management is not the responsibility of an individual software developer.
That responsibility belongs to the organisation.
But every architectural decision, every meaningful design principle and every well-considered name either helps preserve that understanding...
...or slowly allows it to disappear.
My own role changed considerably during those forty years.
In the early eighties I wrote almost every line of software myself.
Later I spent much more time designing systems, reviewing architectures and coaching development teams.
I still enjoyed programming and occasionally became involved in the more challenging implementation details.
Especially when somebody confidently explained that something was "impossible to program."
Those discussions were usually the most enjoyable.
Gradually I realised that software itself is only one of the deliverables.
The other deliverable is knowledge.
Software without its underlying reasoning eventually becomes difficult to maintain.
Not because the code is poor.
But because future developers are forced to rediscover decisions that had already been made years before.
Looking back
Every organisation has its own way of developing software.
Every team has its own standards, methodologies and tools.
Every developer eventually develops a personal style.
Those are simply different roads.
What matters is not the road itself.
What matters is where the journey begins...
...and what survives when the journey ends.
It should begin with understanding WHY.
And it should end with preserving WHY for everyone who follows.
Because software is much more than source code.
It is accumulated organisational knowledge.
Technology will continue to evolve.
Our development processes will continue to evolve.
The tools we use today will eventually be replaced by better ones.
But the purpose remains the same.
To understand the problem before solving it.
And to ensure that the reasoning behind our decisions survives long after we are gone.
Everything else is simply the road from ideas to working software.