The document discusses managing legacy code from the perspective of a project manager. It describes the challenges faced by development teams in supporting poorly organized legacy systems with unrealistic deadlines. While rewriting the system from scratch would improve maintainability and performance, it is a high-risk option that the business may not be willing to fund. The best approach is to gradually transition features from the legacy monolith to microservices over 1-3 years, starting with a proof of concept pilot project to demonstrate the benefits and gain approval for further work. This allows keeping the existing system running while developing new capabilities correctly with defined architecture boundaries. Success requires buy-in across the organization and a dedicated team to lead the transition.

2. Ekaterina Shalapanova,
Delivery Manager
Lviv, 2018
Managerial perspective on legacy code

3. How to get a
Legacy system?
Product
Legacy
Sticky
Tape
Monolith
Spaghetti

4. • This app is impossible to support, at all!
• Their deadlines are non-realistic, you see. Just a single regression testing cycle
takes us here 4-5 man/month!
• It should be rewritten using some good and maintainable technology!
• Performance will never improve till this crap is rewritten completely
• That BA is insane! This is absolutely not possible to add a new type for this entity,
this will require to touch that module no one understands, and I cannot guarantee
the code would even compile after this
• Please transfer me to a good project
What Your Team Say

5. • Guys, what the hell, you are professionals, and we need the quality!
• What?! Adding a couple of buttons on a typical screen is gonna take three bloody
weeks!
• Your company is big, please find us some true professionals, who can write good
code
• OK, we understand what legacy is, but Business needs these features to be
delivered by <some very important event> in 3 weeks, we’ll pay overworks!
• Hire more QA, Dev, DevOps, BA!
What Your Client Say

6. • A plague o' both your houses!
• Even if I add more people, this code is so poor organised that they will just
interrupt each other and slow down the whole process
• They never give us enough time us to complete the refactoring, and last time we
did that, it cost us additional three days for the merge into those spaghetti and a
two-week nightmare of the stabilisation.
• I wish I worked on a better account!
What the PM Thinks

7. “Who is to Blame?” and
“What Is To Be Done?”
The most useless thing in your circumstances is to seek for someone who is guilty.
There is never a single person here, there is always a chain of decisions made, and
each of them was a right one at that moment.
Anyway, there are always a few options:
• Do nothing
• Throw this stuff away and rewrite it using some modern technology and
architecture
• Do not throw this stuff away, do not rewrite it, but still do something

8. Pro Contra
No changes to a running system
This one is working somehow
Your client’s unhappiness will last
Your team unhappiness will last
In a year or two this will be a complete disaster
Do nothing
Go this way if:
• This product won’t last for more then a year
• You plan to leave your company in a few month
• You are not interested in the personal and professional growth at all

9. Pro Contra
You are going to have a new cool fancy
product
This is a business decision and out of the scope of IT.
Client may just not have enough money.
They will finally meet all the non-
functionals you and the client need
Legacy is rarely well-documented, the risks of doing
something different are too high
Your development team is going to be
happy
This is a moving target
Your users are going to be happy
Throw this stuff away and rewrite it completely

10. Throw this stuff away and rewrite it
completely – II
Go this way if:
1. Client has money and, what is more important, they have people who understands
the current system, and these people are available for IT
2. You have the buy-in not from only the IT-department
3. Your stakeholders understand their risks better then you and are ready to share
the responsibility, and help you on the daily basis.

11. Do not throw this stuff away, do not rewrite it,
but still do something
Combine two basic:
• never change a running system
• change something
This contradiction can be resolved by applying an architecture that allows keeping
the old system “as is” and all the new big features are to be developed in a correct
way and use the old functional via some interlayers

12. 1. Get an inspiration from a (micro)service architecture and develop the system
target state and this will give you strict boundaries
2. Choose a feature that can be easily developed as a separate service and, thus,
can be used it as a POC
3. Develop a roadmap for the target state (move the features one-by-one from
“monolith” to “services” (realistically, it will take 1-3 years)
4. Do the POC and go further
How we do this

13. 1. One who is able to develop the concept of the rework, sell this idea to both you
and your team and the client’s stakeholders
2. Understanding or even desire to change from the client’s side
3. A low-risk guinea pig feature to start with
4. Focused PM and architect who believe in their mission
Necessity and sufficiency

14. 1. Is there is something that can decrease the POC time-to-market, use it
2. Your old team may be tired of the legacy and sometimes it make sense to let
some of them go and replace with engineers who are enthusiastic about their
“mission”
3. But you still need the knowledge of the system as your system is likely poorly
documented
4. Constantly invest into improving your QA and Requirements management
process
To increase your chances

15. Do we have some time for a discussion?