How to onboard a legacy software project smoothly? Part 1 | IT's time to talk #7

00:00 → 00:04

Ladies and gentlemen, legacy code is one of the

00:04 → 00:07

biggest pain points of all software engineers.

00:07 → 00:10

Today, with our presales engineers and software

00:10 → 00:14

architects, Kacper Świętkowski and Krzysztof Sikora,

00:14 → 00:18

we will discuss how to make onboarding of a

00:18 → 00:22

legacy project from one team to another possibly smooth.

00:27 → 00:30

Gentlemen, I'm super, super glad to have you here.

00:30 → 00:31

How are you doing?

00:31 → 00:34

Doing good. Thank you, Michael.

00:34 → 00:37

Good. Good. Good. Thank you for having us here.

00:37 → 00:38

Yes.

00:38 → 00:40

Today's show will be super transparent because we all

00:40 → 00:42

decided not to blur our backgrounds.

00:42 → 00:44

Oh, I think that Krzysztof blurred his background.

00:44 → 00:45

I blurred.

00:46 → 00:49

Never mind. So okay.

00:49 → 00:52

Let's talk about the legacy.

00:53 → 00:56

Please tell a few words about the characteristics of legacy projects.

00:56 → 00:59

I mean, they may sound obvious.

00:59 → 00:59

What is, let's say,

00:59 → 01:03

the main difference between working on a greenfield project and something,

01:04 → 01:05

let's say, legacy related?

01:05 → 01:08

But how does it look like from your perspective?

01:08 → 01:11

So to me, the most important part is actually to

01:11 → 01:15

understand why the current vendor is going to be

01:15 → 01:19

replaced, what are those issues,

01:19 → 01:23

and if we can actually fix them and perform better.

01:23 → 01:26

Because, that's the most important part.

01:26 → 01:29

If I can identify those issues

01:29 → 01:34

easily, propose solution that I know that I can deliver

01:34 → 01:37

the quality or the value to the customer, and this is, like,

01:37 → 01:39

the most important part.

01:39 → 01:44

To me, obviously, the difficult part is actually

01:44 → 01:47

to correctly identify those issues.

01:47 → 01:52

Very often, customer can only see the tip of

01:52 → 01:55

an iceberg, and the underlying causes are not that

01:55 → 01:58

clear at the first site.

01:58 → 02:01

But but this is

02:01 → 02:06

basically our approach when it comes to legacy code.

02:07 → 02:08

Alright. Christophe? Yeah. Yeah.

02:08 → 02:11

So kind of addressing your question,

02:11 → 02:13

what is legacy?

02:13 → 02:17

I think it can mean different things.

02:17 → 02:20

I mean, some people say that once the code is written,

02:21 → 02:22

it becomes legacy.

02:22 → 02:25

But, I mean, usually, I guess,

02:25 → 02:31

we talk about systems that have been around for quite some time,

02:32 → 02:35

like, five years, maybe even a a decade.

02:35 → 02:38

And I would say I usually

02:39 → 02:43

kind of sense, like, a system coming our way when you see

02:43 → 02:44

certain indicators.

02:44 → 02:47

Like, people say, okay.

02:47 → 02:51

No one works to no one wants to work on

02:51 → 02:52

this on this system.

02:52 → 02:55

Or, like, we lost key developers or it's very hard to

02:55 → 02:57

change or

02:58 → 03:02

there are outages or problems that the customer or or

03:02 → 03:05

the owning team cannot really identify.

03:05 → 03:09

So I think we could go on and identify a set of

03:09 → 03:14

indicators that can really classify a system as as a legacy

03:14 → 03:18

that is not actively kind of maintained

03:18 → 03:22

and is resting with time

03:23 → 03:24

more and more.

03:24 → 03:28

So what do you consider while reviewing potential projects for Handover?

03:28 → 03:31

Do you analyze performance, security issues,

03:31 → 03:33

market related value?

03:33 → 03:34

How does it look like?

03:34 → 03:36

First of all, I would consider, like,

03:36 → 03:38

success criteria.

03:38 → 03:42

So everything that you said is obviously

03:42 → 03:48

important, but I usually there are already some

03:48 → 03:51

pain points that are recognized by the customer

03:51 → 03:55

and understanding what's what's need to

03:55 → 04:00

be fixed and what are those issues are, like,

04:00 → 04:02

the most important one.

04:02 → 04:05

For some, it might be performance.

04:05 → 04:08

For something else, there might be security issues

04:08 → 04:14

or some outages as Shustov said.

04:14 → 04:18

It's very, very, very difficult to

04:18 → 04:24

give you just one answer for every case.

04:24 → 04:28

So there's usually process of understanding

04:28 → 04:30

the the the current situation of

04:30 → 04:34

the client and propose proposing a solution for that.

04:34 → 04:34

Yeah.

04:34 → 04:36

From presales perspective,

04:36 → 04:38

I I cannot really stress more understanding the current

04:38 → 04:41

business situation of the customer.

04:41 → 04:41

So

04:43 → 04:46

where they are at the moment, what problems do they face,

04:46 → 04:49

what is their, like, long term strategy,

04:49 → 04:53

are they willing to expand the business,

04:53 → 04:56

do they have specific needs

04:56 → 04:59

or requirements with regards to the system?

04:59 → 05:02

So I think understanding this is really key,

05:02 → 05:04

to decide on further steps.

05:04 → 05:08

And only then we can go into into technical analysis of what

05:08 → 05:11

the system is, what the tech stack is, doing code reviews,

05:11 → 05:16

and maybe analyzing the the kind of further requirements.

05:16 → 05:20

Because sometimes we see that the customers jump into

05:20 → 05:22

conclusions and,

05:23 → 05:26

do not really do this analysis up

05:26 → 05:28

front, and they want to have a new system,

05:28 → 05:33

which might be the the eventual decision

05:33 → 05:35

that is to be taken.

05:35 → 05:38

But I would really, encourage and,

05:38 → 05:43

take the time to properly understand what is

05:43 → 05:45

the problem and what is the goal.

05:45 → 05:48

So To give you an example,

05:48 → 05:53

customer may be not satisfied with

05:53 → 05:55

the velocity of the team,

05:55 → 06:00

so the pace that the current team is working on a software.

06:00 → 06:03

But, actually, the root cause for that can be

06:03 → 06:04

organizational.

06:04 → 06:08

So for instance, there is an increasing amount of technical

06:08 → 06:12

debt, and that makes the current team slow.

06:12 → 06:15

Maybe their the maintenance cost is growing,

06:15 → 06:20

or maybe the code and main

06:20 → 06:23

attainability is very high.

06:23 → 06:26

And sometimes there there are even, like,

06:26 → 06:30

HR issues where where a company cannot

06:30 → 06:32

rotate properly.

06:32 → 06:36

And if the project lasts for multiple years many years,

06:36 → 06:41

you can expect people change over time.

06:41 → 06:43

And then there are, like, many issues,

06:43 → 06:47

like lack of documentation might be an issue,

06:47 → 06:51

like lack of new talents and the ability to

06:51 → 06:55

gain new talent and onboard new talent to the team.

06:55 → 07:01

Sometimes the issue is with the growing

07:02 → 07:04

number of the team members.

07:04 → 07:07

So when the

07:07 → 07:11

platform was small and the team was small,

07:11 → 07:14

it was quite easy to develop.

07:14 → 07:18

Right now, because of the a sure amount of the

07:19 → 07:21

line code that is already been written,

07:21 → 07:24

changing anything may be very difficult.

07:24 → 07:27

And the issue is actually in the architecture.

07:27 → 07:32

So there there are, like, many, root causes,

07:32 → 07:36

like, plausible, for a

07:36 → 07:40

simple, pain point, which is the team

07:40 → 07:44

is not delivering in the pace that will satisfy us,

07:44 → 07:46

which maybe it's not, like,

07:46 → 07:49

longer feasible from, like, ROI

07:49 → 07:51

perspective.

07:51 → 07:56

Okay. So it's not, let's say, just an engineering challenge.

07:56 → 08:00

This may be a decision of a personal

08:00 → 08:02

or business background.

08:02 → 08:06

Does it mean let's focus on the business aspect.

08:06 → 08:10

We are about to take over a

08:10 → 08:12

project that is a legacy project and we recognize

08:12 → 08:17

business issues, it is is it beneficial to involve in such

08:17 → 08:21

process someone, let's say, from user experience team,

08:21 → 08:23

like someone who's doing research,

08:23 → 08:26

like a business analyst, that kind of person?

08:27 → 08:29

Obviously, it depends.

08:29 → 08:32

So if this is, like, back end system,

08:32 → 08:35

which is going to integrate to back end,

08:36 → 08:40

like, third party systems, maybe the UX is not needed.

08:40 → 08:45

But sometimes, yeah, you can eliminate much of a

08:45 → 08:49

customer support that is needed just improving the UX.

08:49 → 08:53

So there might be a situation when the current team is

08:53 → 08:57

overwhelmed with the customer support that is needed,

08:57 → 09:00

and you can solve that with improving UX.

09:00 → 09:02

Okay? So this is totally possible.

09:02 → 09:06

But this is just one of possible branches how the

09:06 → 09:08

current situation can be fixed.

09:09 → 09:09

Yeah.

09:09 → 09:12

And I can kind of counterbalance this with an

09:12 → 09:16

example from the past where a key part of

09:17 → 09:21

conquering a legacy system rewrite and transition was to

09:21 → 09:25

have a proper business analysis done Because a system that

09:25 → 09:27

initially was

09:28 → 09:32

mainly used by by the customer care turned out to be

09:32 → 09:36

so much kind of connected into many

09:36 → 09:39

departments, like finance, reporting,

09:40 → 09:44

kind of even even daily operations of the company that

09:44 → 09:47

from one stakeholder, the project turned out into, like,

09:47 → 09:50

a stakeholder board project because

09:50 → 09:54

there were so many things not really seen

09:54 → 09:58

initially on in the UI level.

09:59 → 10:03

For example, the system was used as a compliance

10:03 → 10:07

I mean, it was used for financial purposes in terms of

10:07 → 10:10

reaching a compliance in in the bookkeeping.

10:10 → 10:12

So

10:13 → 10:15

things like that can really surprise you.

10:15 → 10:16

So

10:16 → 10:19

Speaking about more complex enterprise type types of

10:19 → 10:23

systems that have been around for decades, and usually,

10:23 → 10:26

each company has such a system that was written in the

10:26 → 10:30

beginning and was covering many different areas.

10:31 → 10:33

These are really interesting cases.

10:33 → 10:36

So, proper analysis and then,

10:36 → 10:39

really splitting away different parts

10:39 → 10:43

of the system to satisfy new business requirements is is one

10:43 → 10:46

of the ways to go, and

10:47 → 10:50

that's that's sometimes the reality.

10:52 → 10:55

Okay then. Thank you very much.

10:55 → 10:58

We talked a little bit about the business aspects,

10:58 → 11:03

personal aspects, but let's focus now on engineering.

11:03 → 11:05

Very often when we take over,

11:05 → 11:08

even at the presales stage,

11:09 → 11:12

a legacy project, we conduct a code review.

11:12 → 11:12

Yes.

11:12 → 11:16

We take a deeper look in the repository that that

11:16 → 11:19

is shared with the client by the client,

11:19 → 11:24

and we tend to analyze to get at least some very initial orientation.

11:25 → 11:29

Are there any good practices that a person conducting code

11:29 → 11:30

review should follow?

11:30 → 11:32

Are there any, let's say,

11:32 → 11:36

advices that you would be able to give?

11:36 → 11:41

What we need to remember about while conducting a code review?

11:41 → 11:44

So I would say that, first of all,

11:44 → 11:48

you need to understand the limitations of code review.

11:48 → 11:52

So So not everything may

11:52 → 11:54

be included in the code review.

11:54 → 11:56

To give you an example,

11:56 → 12:00

you can have exactly the same query that retrieves a

12:00 → 12:05

user from a database which contains one

12:05 → 12:08

thousand users or one hundred thousand users,

12:08 → 12:11

and the system is completely different.

12:11 → 12:14

And the complexity

12:14 → 12:16

operating on such a

12:17 → 12:19

system is totally different.

12:19 → 12:21

So this is one thing.

12:21 → 12:22

So

12:24 → 12:29

the infrastructure and the context of the software is very important.

12:29 → 12:31

So that being said, for instance,

12:31 → 12:36

if you've got a software that is used

12:36 → 12:40

by a desktop employee and is going to,

12:40 → 12:43

I don't know, make some reports

12:44 → 12:48

Quarterly, and it crashes, like, once a year.

12:48 → 12:49

It may be painful,

12:49 → 12:52

but maybe this is something that is acceptable.

12:52 → 12:53

But on the other hand,

12:53 → 12:56

if you've got a train company

12:56 → 13:00

And your software causes train to crash once a

13:00 → 13:04

year, this is, like, completely different

13:04 → 13:08

requirement for the code quality.

13:08 → 13:12

So, like, prior to code quality,

13:12 → 13:15

we need to understand the the the

13:17 → 13:19

the severity of certain issues,

13:19 → 13:24

and then we can assess if given code will

13:25 → 13:28

will be sufficient enough to

13:29 → 13:33

be actually a solution of a problem that is stated.

13:33 → 13:34

So this is one thing.

13:34 → 13:37

And other later on, like, obviously,

13:37 → 13:40

you can focus on some smaller issues like

13:41 → 13:43

how the database is handled.

13:43 → 13:47

Is this something that is readable?

13:47 → 13:48

Very often,

13:49 → 13:52

during the transition period, you may expect some

13:52 → 13:54

walkthrough of the code,

13:54 → 13:58

but you need to remember that this walk through is

13:58 → 14:00

going to be

14:01 → 14:07

done by a company that maybe is not that interested

14:07 → 14:11

into you understanding fully what's going on.

14:11 → 14:13

So at the end of the day,

14:13 → 14:16

you need to make sure that you'll be understand you you'll

14:16 → 14:20

you'll be able to understand what's written in this code.

14:20 → 14:23

So this is one one thing.

14:23 → 14:24

And

14:25 → 14:27

one very important,

14:28 → 14:32

I would say, issue that may be understood from the code

14:32 → 14:36

is actually third party dependencies.

14:36 → 14:41

Very often, they may be not documented,

14:41 → 14:43

and it's

14:44 → 14:48

it's still so much easier

14:49 → 14:52

to understand what's written in

14:52 → 14:55

the code base that you have access to

14:56 → 15:00

comparing to using some other services that may be

15:00 → 15:04

legacy as well, and they are not documented and you don't

15:04 → 15:05

know how they work.

15:05 → 15:10

They are not built by their team that you're going to replace.

15:10 → 15:13

So this

15:14 → 15:20

like, these moments are actually what we're looking for.

15:20 → 15:20

Okay?

15:20 → 15:24

Some external dependencies that no no one is actually

15:24 → 15:27

aware of, even the customer itself.

15:28 → 15:33

When you've been saying about the train companies,

15:33 → 15:36

can I remind myself that about this advertisement that was

15:36 → 15:41

released recently that the German state railways,

15:41 → 15:45

they've been looking for a guy knowing Windows three eleven

15:46 → 15:50

because their schedules and everything is still relying on floppy disks?

15:50 → 15:50

Yeah?

15:50 → 15:54

And and they needed and they needed someone who

15:54 → 15:57

basically they knew the technologies that been commonly

15:57 → 15:58

used thirty years ago.

15:58 → 16:02

But and they couldn't give it away because it works. Yeah?

16:02 → 16:04

And they are super afraid of even touching it.

16:05 → 16:05

Yeah.

16:05 → 16:09

Risk management is a huge part of taking

16:09 → 16:11

over legacy platform.

16:11 → 16:13

That's that's for sure.

16:15 → 16:19

So sometimes we can do more damage than solutions.

16:19 → 16:22

So we and we need to be aware of that.

16:22 → 16:24

Okay then.

16:25 → 16:26

Speaking about legacy.

16:26 → 16:30

Speaking about more engineering aspect of legacy.

16:30 → 16:36

What about moving from monolith to arc to microservices architecture?

16:37 → 16:42

We get more and more requests of that kind.

16:42 → 16:43

And

16:44 → 16:49

and sometimes we are surprised learning that in some

16:49 → 16:51

projects, this is not a necessity,

16:51 → 16:53

and it's not even recommended.

16:53 → 16:57

What is your fault about moving from monolith to

16:57 → 16:58

microservices?

17:00 → 17:04

I I think it's it's usually a buzzword for many people.

17:05 → 17:09

Like, any of the the patrons that are high level might

17:09 → 17:11

be, you know, serverless or whatever,

17:11 → 17:13

and they have heard it.

17:13 → 17:17

Maybe it worked for a company they have been talking to,

17:17 → 17:20

and they've looked at the upsides and the benefits,

17:20 → 17:24

and they want this to happen over their system.

17:24 → 17:25

So

17:25 → 17:28

as has as has been already said,

17:28 → 17:33

there is no one solution if you don't, and we would usually, again,

17:34 → 17:38

go back to square one and analyze what is going on with

17:38 → 17:40

the system, what is wrong,

17:40 → 17:45

and if if really microservices might be a solution.

17:45 → 17:47

And if if it is, like,

17:47 → 17:51

it looks that this might be a solution, we would really,

17:51 → 17:55

very rarely advise to split and model it into micro

17:55 → 17:58

services and define as a project goal.

17:58 → 18:00

We would usually

18:00 → 18:04

mix the current, business opportunities and

18:04 → 18:08

challenges with introducing new services and

18:08 → 18:10

then maybe splitting away, like,

18:10 → 18:13

peeling the current system, from features.

18:13 → 18:17

So this would this would be be this kind of

18:17 → 18:21

evolutionary approach into the architecture,

18:22 → 18:25

you know, unless this is really an

18:25 → 18:28

obvious case, which is very rare.

18:29 → 18:32

So we have seen so many

18:32 → 18:36

microservices architectures going wrong, and this is also

18:36 → 18:41

quite it is also quite quite good amount of proof in

18:41 → 18:44

the literature that with that

18:44 → 18:48

as any other high level architecture or

18:48 → 18:51

product, you need to be really careful.

18:52 → 18:52

Yeah.

18:52 → 18:54

So

18:55 → 18:59

what I can add to that is

18:59 → 19:03

that, like, having microservice architecture is not

19:03 → 19:05

a property of the software.

19:05 → 19:08

So If you you want to consider, like,

19:08 → 19:12

architectural drivers, and this is, like,

19:12 → 19:15

maintainability of the code and

19:15 → 19:17

scalability of a code.

19:17 → 19:21

And then you can actually say if those markers are going

19:21 → 19:25

to improve because of that or the other way

19:25 → 19:31

around, we will introduce unnecessary complexity to the problem.

19:31 → 19:35

Some indicators that microservices might be a

19:35 → 19:38

good approach would be, for instance,

19:38 → 19:41

growing team

19:42 → 19:42

size.

19:42 → 19:43

Alright?

19:43 → 19:47

And you no longer can operate and merge

19:47 → 19:51

between each branches is going to take forever,

19:51 → 19:55

and it's very difficult to handle team of maybe twenty people.

19:55 → 19:59

Then we might might split the monolith

19:59 → 20:03

architecture to smaller team that are more agile,

20:03 → 20:06

more they can go faster.

20:06 → 20:08

The other way

20:09 → 20:12

other consideration is actually risk handling.

20:12 → 20:16

So imagine that you've got your legacy platform and you want

20:16 → 20:19

to rewrite that.

20:19 → 20:23

As you said, sometimes it's very difficult from

20:23 → 20:27

the risk from the perspective of the the the security

20:27 → 20:31

of the platform to rewrite everything at once.

20:31 → 20:35

So what you can do is split the current software into, like,

20:35 → 20:39

smaller pieces and rewrite piece after piece.

20:39 → 20:44

So with this approach, there's, like,

20:45 → 20:49

much lower risk that you will fail

20:49 → 20:50

tremendously.

20:50 → 20:51

Okay?

20:51 → 20:54

So you limit the the the possible

20:56 → 20:57

possible,

20:58 → 21:00

like, burnout.

21:00 → 21:04

Like, with the smaller project, every risk is reduced as well.

21:04 → 21:07

And the second part is scalability.

21:08 → 21:11

Very often, if you've got, like, monolith platform,

21:11 → 21:14

you'll end up with one database,

21:14 → 21:19

which usually is bottleneck when it comes to, rights.

21:19 → 21:20

So if this is the issue,

21:20 → 21:24

then probably some approach,

21:24 → 21:28

like CQRS, might be useful.

21:28 → 21:31

So you can actually split your platform and

21:31 → 21:34

scale the pieces of the platform

21:34 → 21:35

independently.

21:35 → 21:39

So that's the the the that's that is proved to be

21:39 → 21:41

a very

21:42 → 21:47

effective approach, but only when it's needed.

21:47 → 21:51

So the the the main call to the

21:51 → 21:56

microservice microservices is increased

21:56 → 22:00

complexity and the amount of communication between the

22:00 → 22:02

microservices.

22:02 → 22:05

So, definitely, it's not

22:06 → 22:12

a bullet point bullet silver bullet that will fix every software.

22:12 → 22:15

I hope you enjoyed the first part of our

22:15 → 22:19

conversation on legacy projects.

22:19 → 22:24

We decided to cut this episode into two, and

22:25 → 22:28

additional questions will be asked in the second part.

22:28 → 22:30

Thank you. Have a great day.