We all have seen software being marked as obsolete and named legacy. A messy thing that no fellow Engineer would like to touch, a cost in time and sanity to keep up with something that we would rather throw away and start all over. But even the new, one day, sooner rather than later, will become legacy. These are bad news but also good news, in a way what you are doing now is the legacy yet to come. So you can take action now and prepare.
There are a few culprits: negligence, ossified design and failure in passing the knowledge. Words that have the opposite meaning of what I would call legacy.
The antonym to software legacy
Things change, improve and evolve and in the end become something else, which is possible due to their legacy. I will revisit a key concept that, while simple, took more than one lifetime to be understood.
Copernicus once made the correct but dangerous observation that planets revolved around the Sun. His theory took more than one century to be proven correct.
Tycho Brahe, a wealthy astronomer, once asked his assistant to define Mars orbit. Brahe had a lifetime of Mars observations that only at his death passed down to his assistant. In a way Brahe was afraid that his assistant, Kepler, used such legacy to prove Copernicus correct (as Brahe had his own Earth centred model). Using these observations Kepler found that the orbits of the planets followed three laws. But this was no easy endeavour. Similar to Copernicus he believed that orbits were perfect circles around the Sun. But these observations made clear that planets orbits were in fact ellipses, each one with one of their focus at the Sun.
For the known planets at the time Kepler’s 3 laws worked as advertised, but what about everything else that was not a planet? It was Newton that explained the mutual attraction of bodies with his law of gravity, such as when a tree lets an apple fall down to Earth. Such force was then proved to be the same one holding the Moon and Earth together. He went as far as showing that such bodies follow an elliptical path like Kepler first law described.
Delembre computed tables of planetary positions for Jupiter, Saturn and Uranus but found that this model (using the law of gravity) had some discrepancies with observations regarding Uranus, therefore he wrote:
… I leave it to the future the task of discovering whether the difficulty of reconciling [the data] is connected with the ancient observations, or whether it depends on some foreign and unperceived cause which may have been acting upon the planet.
Some argued that Newton’s law was not universal (just until Saturn at the time), others made the right observation that maybe a planet far out was in play. Only when Neptune was discovered hearts felt at ease with Newton’s law.
Newton described gravity, but he had no idea how it worked, it was Albert Einstein 300 years later that described General Relativity.
Bernard of Chartres used to compare us to dwarfs perched on the shoulders of giants. He pointed out that we see more and farther than our predecessors, not because we have keener vision or greater height, but because we are lifted up and borne aloft on their gigantic stature.
Our legacy is built on the shoulders of what came before, we reach far because of it.
Respect for legacy
It is important to build upon what came before such was only possible because there was a transfer of knowledge, a model and architecture that changed together with new observations and didn’t ossified in a perfect circular motion. This is the humble feeling that our contributions will outlive ourselves.
So I would describe legacy in software as:
- Building on a solid ground: test driven development should embody what the software purpose is and allows it to move with confidence and adapting to changes. Or, better yet, pave the way for our fellow engineers to be successful.
- Knowledge sharing: documenting the Domain of our software. Don’t focus on technology alone as, it is there to solve a problem in a given domain not the other way around. Decouple it. Use an ubiquitous language that Domain experts can understand and contribute to.
- Don’t ossify in any given design: any contribution to the software should be able to improve it and change, refactor often, improve often. This confidence is validated by TDD (Test Driven Development) and clear documentation, Remember you can only improve what you understand and should have the confidence to do so.
While there are a few frameworks to work with software rot, the best way to handle it is to prepare for it by, designing your software for it. Envision yourself as part of the past, collect those planetary positions that one day someone will make sense of, remember that in your team QA is not serving the present but documenting for the future. And any past person or team that worked on the software you want so much to throw out of the window and remake because you flagged it as legacy has important value to add to it, Even if it’s not true be that positive energy of change yourself.
My final two quotes goes to Albert Einstein comment on Isaac Newton work:
…forgive me; you found the only way which, in your age, was just about possible for a man of highest thought — and creative power. The concepts, which you created, are even today still guiding our thinking in physics, although we now know that they will have to be replaced by others farther removed from the sphere of immediate experience if we aim at a more profound understanding of relationships…
and one that is attributed to many famous persons in our history but I often hear from my wife (and that’s the voice that is more dearest to me):
Be the change that you want to see in the world
Originally published at medium.com.
