- Expect nothing
- Blame nobody
- Do something
No escape path
Legacy projects and legacy code is everywhere … The common myth that startups are all about green fields and butterflies is not a full truth; quite often it is a battlefield full of blooding developers corps and continually changing winds and requirements. It is hard to escape from a legacy or even escape to create a legacy.
It reminds me some times a tower game.
You have a random setup that was before you.
Your next move dictated by external conditions.
Legacy - Trash or Treasure?
- something that is a part of your history or that remains from an earlier time
- money or property that you receive from someone after they die
- a situation that has developed as a result of past actions and decisions
So as you can see it is all about money and history, a result of past actions.
On a keynote about a legacy - it is often old code some of this code is even older than you.
It is usually successful - if the company still exist.
So the code generates money and solve customer goals.
Legacy generates money.
In 2005 I had built a COBOL transpile systems that migrate a project from the 70s that was older than me and generate a tonne of income.
Beyond the code
The values and people
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
For me, it is more about teams and people. Any organization is just a people and relations in between together with a full specter of emotions and irrational human nature.
You could change all code base, but it is much harder (probably) impossible to change people and organizations.
Before to apply to a job and challenge try to understand if you are ready to work within an organization and their values.
Team view
For engineering team. Existing codebase could be perfectly fine.
A team could be keen to work on Java 6 in the middle of 2018 or do a backbone or vanilla ECMA script 3 and be happy with it. One more warning sign is don’t touch my code mindset.
Management view
Some times company leadership not aware of tech dept or legacy. Make sure that all on the same level of understanding.
Legacy code
Why it exists?
- The enormous amount of time and investments.
- Any new if a next old.
What is it?
Let’s go to the level of code finally what the legacy code is?
Like many people, as many definitions
the source code that relates to a no-longer supported or manufactured operating system or other computer technology
More classical view
code as code without tests.
Fifty shades of developer complaints …
code that you not comfortable or confident to change.
i dont understand it…
Less seasoned feedback.
the code was written before me or code that was written not by me.
my granny tech stack
The road to failure is constant migration to on “Edge technologies.”
It is in most cases not about outdated technologies. I have seen a lot of old projects that failed utterly to migrate on “more modern” stack or replace a library X.
It is not Angular seven code
What is really about?
The critical factor is confidence to change.
F.E.A.R
For me, it is all about how we deal with changes. I have seen code from 1975 on COBOL that was so elegant and clear and written practically as spec by business folks. I have witnessed forth the code of space ship control system that was state of the art.
For me, the dark side of Legacy is a FEAR.
Is fear to fail, fear of change.
You have two roads to deal with fair.
- Forget everything and run
- Face everything and raise
The choice is on your side.
Be brave!
The collective legacy over time.
We already mention Conway Law. A code is a reflection of organizations and people. Quite rare it is a fault or success of a single person.
Usually, we have several contributions:
- constantly changing requirements.
- corporate sclerosis - code maintained with a generation of developer that not overlap in time, knowledge quite often gets lost.
- the layers of feature and bug fixes.
- non-functional constraints that change over time.
It is a complex cognitive task - to understand code base created by different personalities distributed over time with different conditions.
Be open and be curious about your colleagues and ex-colleagues. It is all about read other people code
It is more like a collective letter to parent from one of my favorite cartoon
One more fun illustration about the topic broaken phone game
No Good, No Bad.
For me the good code is:
- generate money
- solve real customer problems
- easy to change
All other is cherry on the pie.
How to be successful with legacy?
Do not demotivate yourself and folks around
Don’t blame and complain if you are not going to make it better.
Negative mindset never gets you to positive results. It is easy to set your self to a victim role - pls don’t.
Be careful about what you say especially if you have junior developers around.
I know you frustrated, and maybe struggle - don’t make it deeper.
Find yours why
- Set clear and internalized personal goals.
- Find something positive about it.
The good parts of the legacy:
- it is successful
- customers like it
- you have a job
- you could learn a lot and make an impact
Ownership
It is yours - accept it, and don’t be alone
Now it is your code.
So simple mantra
- Expect nothing
- blame nobody
- Do the best
Involve team
From the other side, you should stay vocal about a challenge that you were facing. It is crucial if you are new to a team/company. Share findings, document code, ask about the reasons behind.
Involve business
Key of success - is to understand what we should do?
What the expectations and show how we could achieve results?
Before you create an action plan, try to get as much as you can for “business why.”
Explain why you think that it is time to change anything.
Set clear expectations
As far as all on the same page.
Set clear expectations and make sure that everybody is aware.
I have seen a lot of folks that did a great job and failed to explain to others or didn’t in a wrong moment.
Make it incremental with visible and measurable results.
- Be transparent and vocal
- find a way to visualize the results of your work
- Create a constant flow of small wins
Learn as much as you can
It was a reason behind. Learn it.
It is rare that code was created without reason.
You will save a lot of energy if you assume that code has reasoning and system behind.
Always start from assumptions that we all adequate people.
Try to understand:
- business logic
- history
- tech stack
- requirements
- etc
- tech and non functional constraints
Some of the contributors still could be a part of the team.
- Learn from them
- takes care of there emotions
Lean the code …
After you get a reason and business view, try to get Bird view of the code.
Do not focus on particular bed parts. Make marks and notes, put grades and move forward.
Code newer lie.
Visualize !
I use a lot of tools that turn code to visual graphs
Get a bird view.
dependensies
So the hihgest view is a module compositions and dependensies:
Visualize a dependensies
dependency cruiser - allow you not only make it visual but set up rules and validate them over a project.
callstacks and callstack visualization.
Next level is a call stack. You should identify project input and outputs and then study a call stack.
- flame charts are cool tools (call stack visualization)
So 0x and similar tools could be used not only for perf analytics but for code visualization tool.
callgraph try to build a static call graph.
Code flow
flowmaker. Code flow could be a visualized as a flow chart.
The flow chart or activity diagrams are easy to understand.
Lean the history
Deeg to git history, issue manager, bug reports. Reconstruct timeline.
- Jira
- Git
- logs
- emails streams
- alert systems
- teammates
The momentum
- Don’t rush to change code without an understanding of logic or constraints.
- Create a change road map. Get all on the same page.
- Keep a wheel running. You probably were not hired only for refactoring and adding the new cool library.
We all need to sell our ideas to other people. Try to find a proper moment to do changes and invest in legacy.
It should be a balance on feature development and stability improvement.
Safe vs. Right
Find a balance between “do a minimal possible change” and “best practice and right architecture.”
Make fearless changes (How not to become a Legacy Dragon)
Do not become the next legacy dragon. So now you have a context and knowledge! After a few months, you are probably comforted with a code. So how not to be the next legacy dragon?
- Document an architecture
- Document tech decisions
- Document a business logic
- Include a link to the repo, so it is easy to find them
- Add an automation test for your code
- CI/CD
Next time we will talk about a legacy JS.