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

00:00 → 00:00

Hello there.

00:00 → 00:04

Last week, we published the first episode on

00:04 → 00:06

handing over legacy projects.

00:06 → 00:10

Today, please welcome the second part of the episode.

00:14 → 00:17

Have you been ever dealing with a legacy project,

00:17 → 00:21

like a commercial project that has been already taken over

00:21 → 00:25

where from day one, have been handling some very,

00:25 → 00:27

very tough, difficult issues, something

00:27 → 00:31

critical, something security related, something that could

00:31 → 00:36

burn the entire business and put it into dis disgrace.

00:36 → 00:38

Have you been ever dealing with such situation?

00:40 → 00:44

Unfortunately, yes. And this is, like, the the common thing.

00:44 → 00:49

Like, changing vendor software vendor is very painful process.

00:49 → 00:51

So, usually, the company can like,

00:51 → 00:53

tries to postpone that

00:54 → 00:56

as far as possible.

00:56 → 00:59

And you very often,

01:00 → 01:03

when company enters our door,

01:04 → 01:07

it's already quite severe.

01:08 → 01:12

And, yeah, I've worked with with

01:12 → 01:15

software project that had

01:15 → 01:19

security issues very critical from the day one,

01:19 → 01:23

and there's, like, huge amount of pressure to fix them.

01:23 → 01:24

But on the other hand,

01:24 → 01:28

you still have limited knowledge about about the

01:28 → 01:32

system, so you need to make sure that you're confident

01:32 → 01:36

enough to deploy and to fix those changes,

01:36 → 01:39

and you're not going to jeopardize the interest of the

01:39 → 01:40

company even more.

01:40 → 01:43

So, yeah, it's it happens,

01:43 → 01:46

and you need to be very care

01:46 → 01:49

careful in cases like this.

01:51 → 01:53

Alright. And, Krzysztof?

01:53 → 01:53

Yeah.

01:53 → 01:57

I mean, I have this one interesting example of a system that I

01:57 → 02:00

already mentioned of a central admin

02:00 → 02:05

In ecommerce company that was developed as

02:05 → 02:09

the first main system and then spread throughout the company

02:09 → 02:13

used in all of the departments to have an overview of static

02:13 → 02:15

customer and transactional data.

02:15 → 02:18

And the main stakeholder became the the customer

02:18 → 02:22

care with, like, hundreds of agents using it on a daily basis.

02:23 → 02:26

So the problems that we are facing were really, like,

02:26 → 02:28

random and

02:29 → 02:31

unknown downtimes.

02:31 → 02:36

And, literally, it took the team that was already changing

02:36 → 02:40

the system and maintaining the system a couple of good sprints

02:40 → 02:43

and Additional experts from the from the

02:43 → 02:45

company to identify the root cause of the issue.

02:45 → 02:51

And in the end, it did not require really code changes.

02:51 → 02:55

The problems were located within the DevOps and

02:55 → 02:59

container or balancing area of of the app.

03:00 → 03:04

But the lesson learned from this for me was that the

03:04 → 03:07

human factor is super important

03:07 → 03:11

Because there was, like, really strong unwillingness from the

03:11 → 03:14

development team to work with this legacy stack.

03:14 → 03:19

So what I would hear as a product owner those days was like, hey.

03:19 → 03:20

Let's rewrite it.

03:20 → 03:24

We don't understand it. It doesn't make sense.

03:25 → 03:29

Yeah. We tried a couple of times already. It did not work.

03:29 → 03:33

So this was the main thing to overcome to really fix it

03:33 → 03:38

and make it stable because transitioning from

03:38 → 03:41

this legacy project will be anyways

03:41 → 03:43

many years in diverse.

03:43 → 03:45

So that's that's one thing.

03:45 → 03:48

Like, many times the development teams

03:49 → 03:54

keep a keep an blind eye on the business goals

03:54 → 03:58

of of what they're maintaining and just look at this legacy

03:58 → 04:01

system from a technology perspective.

04:02 → 04:05

But, yeah, we succeeded, so everything is possible.

04:05 → 04:09

So development teams often complain about the lack

04:09 → 04:12

of documentation of projects that are

04:12 → 04:13

handled over.

04:14 → 04:16

Do you have, let's say,

04:16 → 04:19

some types of assets that you appreciate the most, like,

04:19 → 04:21

I don't know, diagrams and so on?

04:21 → 04:24

What is useful to take over a project,

04:24 → 04:26

especially if the

04:27 → 04:31

if the assets standing behind it are limited?

04:32 → 04:36

I would probably repeat myself

04:36 → 04:39

and say that documentation of the parts that are not included

04:39 → 04:44

into the code base is crucial just because code

04:44 → 04:48

base by itself is quite good

04:48 → 04:50

documentation because at the end of the day,

04:50 → 04:54

you've got quite concrete explanation of how

04:54 → 04:56

things work.

04:56 → 04:59

Maybe it's not that easy to understand,

04:59 → 05:02

but if you've got, like, enough time,

05:02 → 05:05

you can go through the code base and understand how it works.

05:05 → 05:10

What is usually critical is things

05:10 → 05:14

that are not so called managed dependencies.

05:14 → 05:16

So we Have got those system,

05:16 → 05:20

and we don't have access to the code base, and no one.

05:20 → 05:22

Nobody knows how they work.

05:22 → 05:27

And any documentation on that part usually is, like, very,

05:27 → 05:28

welcome.

05:29 → 05:31

So this is the the one thing.

05:31 → 05:34

In, like, maybe not such

05:34 → 05:36

severe cases,

05:37 → 05:40

like architectural diagrams and

05:40 → 05:43

infrastructure diagrams.

05:43 → 05:45

And

05:45 → 05:48

some test cases are, like,

05:48 → 05:53

very important because you can understand how

05:53 → 05:56

the system works, how to deploy that system,

05:56 → 05:59

and how this system is composed.

05:59 → 06:02

So maybe you can ask further questions.

06:03 → 06:08

Especially, I would consider test cases very

06:08 → 06:12

helpful, but still you need to,

06:13 → 06:14

like,

06:16 → 06:19

have in the back of your head that

06:19 → 06:21

they may be not full,

06:21 → 06:26

and there might be some areas that are not covered by

06:26 → 06:28

the the the the documentation you've got.

06:28 → 06:31

So you need to

06:31 → 06:35

limit your your trust when to dealing

06:35 → 06:39

with such documentation as well.

06:39 → 06:40

Okay.

06:40 → 06:42

Yeah. It's always outdated.

06:42 → 06:43

Never

06:44 → 06:45

never perfect.

06:45 → 06:47

I would even lower the bar.

06:47 → 06:51

It's always highly incomplete even with fresh projects.

06:51 → 06:55

Like, customers come to us with ten months year

06:55 → 06:59

old code base, and, they have something.

06:59 → 07:04

But in the end, it's usually you know, it helps a bit,

07:04 → 07:07

to kind of start into the project,

07:07 → 07:10

but really does not answer, majority of the questions.

07:10 → 07:12

I will just add one more artifact,

07:12 → 07:16

which is architects architecture

07:16 → 07:21

decision record that is really so nice to have if

07:21 → 07:25

you can understand based on that the history of the

07:25 → 07:28

decisions being made and why certain things

07:28 → 07:30

work the way they they do.

07:30 → 07:34

Because it's it's often easy to jump into conclusions, hey.

07:34 → 07:37

They use this or that or it doesn't make sense.

07:37 → 07:41

But, if you understand the context and the history,

07:41 → 07:46

I think it always helps and also kind of allows to not

07:46 → 07:51

to make the same mistakes and not to fix things that

07:51 → 07:52

are like balance.

07:52 → 07:57

So, again, that's something I rarely see,

07:57 → 08:01

and we offer this creating architecture decision

08:01 → 08:05

record as an extra kind of

08:05 → 08:07

documentation entity.

08:07 → 08:10

But I think this is super helpful.

08:10 → 08:14

Unless you have people that are willing to work with you and clarify.

08:14 → 08:17

But, again, changing the vendor legacy system,

08:17 → 08:21

people are gone or really not, contracted anymore.

08:22 → 08:22

Yeah.

08:22 → 08:26

And I would say that there's a survivor bias,

08:26 → 08:29

like the the reverse version of a survivor bias.

08:29 → 08:33

So, usually, when someone wants to change

08:33 → 08:39

the vendor, this is because they didn't have proper documentation.

08:39 → 08:43

So when they struggle with the internal

08:43 → 08:46

rotation, the new team members couldn't, like,

08:46 → 08:49

learn and onboard fast enough.

08:49 → 08:53

So you'll end up with a situation where

08:53 → 08:56

you won't be able to find those documents.

08:56 → 09:01

If you were, probably the need of replacing the vendor

09:02 → 09:04

wouldn't exist in the first place.

09:04 → 09:07

So this is very often the case,

09:07 → 09:09

I would say.

09:09 → 09:09

Yeah.

09:09 → 09:12

I mean, sometimes even people realize, like,

09:12 → 09:14

product owners or stakeholders,

09:14 → 09:17

I don't know what this system is really doing.

09:17 → 09:19

Like, I am not sure about this or that.

09:19 → 09:24

There's no documentation. So much time passed by.

09:24 → 09:26

And, what we start with is,

09:26 → 09:30

a test plan or regression test suite and and all of this stuff

09:30 → 09:31

that are missing.

09:31 → 09:32

So,

09:33 → 09:35

yeah, totally agree.

09:36 → 09:38

Thank you.

09:38 → 09:43

So legacy projects are usually associated with a great

09:43 → 09:46

amount of resources that are already burned.

09:46 → 09:50

And by saying resources, we mean money,

09:50 → 09:52

but also ours.

09:52 → 09:55

And, also, think that we do not like

09:55 → 09:57

called resources, but it means people.

09:57 → 09:58

Yeah?

09:58 → 10:02

And and, usually, when such project is approaching us or

10:02 → 10:06

stakeholders of such projects are approaching us,

10:07 → 10:09

they are already tired.

10:09 → 10:12

Their resources may be limited.

10:13 → 10:16

They might be, let's say,

10:16 → 10:19

exhausted already because of the project,

10:19 → 10:22

that consumed so much time and so many resources.

10:22 → 10:26

What can we do to help people in such situation?

10:26 → 10:30

How can we help organizations that already burned a

10:30 → 10:33

lot to build a project, to build, for example,

10:33 → 10:35

a product that doesn't work yet?

10:38 → 10:43

So I'm a huge proponent of evidence based product ownership.

10:43 → 10:47

So it means that before we are going to do something,

10:47 → 10:49

let's create a hypothesis.

10:49 → 10:54

What are we going to achieve? How are we going to measure?

10:54 → 10:58

Maybe we want to introduce the measurement before we are going

10:58 → 11:03

to implement anything and then make sure that we've

11:04 → 11:06

we've reached our goals.

11:07 → 11:11

First of all, we're going to gain some trust from

11:11 → 11:16

the stakeholders that might be discouraged to to

11:16 → 11:19

continue the project in general even.

11:19 → 11:23

So I think trust is the the most important

11:23 → 11:27

issue, and the best way to to to

11:27 → 11:32

regain trust is to make sure that your goals

11:32 → 11:35

are transparent and they are met.

11:37 → 11:39

So that that would be my approach.

11:39 → 11:42

And, obviously, it depends, like,

11:42 → 11:46

case by case what the goals should be,

11:46 → 11:50

but measuring what matters is is the most important

11:50 → 11:52

part and tracking the progress.

11:52 → 11:54

Okay.

11:56 → 11:57

K.

11:57 → 11:58

I'll Yeah.

11:58 → 12:00

I'll just add, you know,

12:01 → 12:05

really reflecting on on what what was the

12:05 → 12:08

history of of of the development and

12:09 → 12:13

stop pouring money into a leaky bucket Because

12:13 → 12:17

as as you kind of ask the question,

12:17 → 12:21

it's often the case that you put more and more into a legacy

12:21 → 12:25

system, and you really have diminishing results.

12:25 → 12:29

And understanding why, I think it's key

12:30 → 12:34

because there are so many strategies that can be employed

12:34 → 12:38

that this time is really good

12:38 → 12:41

invested before jumping and changing or rewriting

12:41 → 12:44

or whatever.

12:44 → 12:45

So

12:46 → 12:48

that's a big money saver potentially.

12:49 → 12:50

Alright then.

12:50 → 12:54

Gentlemen, one of my last questions thank you again.

12:54 → 12:57

One of my last questions today may may even sound

12:57 → 13:01

stupid, but people ask this question.

13:01 → 13:02

And I think that,

13:03 → 13:05

it's good to, let's say,

13:05 → 13:08

give a little bit of overview to the public.

13:09 → 13:12

If we are taking over legacy project and we know

13:12 → 13:15

that refactoring or even

13:15 → 13:18

replatforming will be required,

13:19 → 13:21

where we should start?

13:21 → 13:22

Shall we start with the back end?

13:22 → 13:25

Shall we start with the front end?

13:25 → 13:29

Shall we, I don't know, work a little bit on the UI,

13:29 → 13:31

on the security?

13:31 → 13:32

What do you think?

13:32 → 13:35

What is a good starting point in a legacy project?

13:36 → 13:39

I would say that ROI is the most important

13:39 → 13:41

metric

13:42 → 13:43

that I would focus on.

13:43 → 13:45

So

13:47 → 13:49

it obviously

13:49 → 13:52

depends on the current issues.

13:52 → 13:56

Maybe we've got a platform where we waste

13:56 → 14:00

tremendous amount of money just because of poor

14:00 → 14:04

click through rate and the acquisition the

14:04 → 14:07

customer acquisition is, like, very high.

14:07 → 14:12

And fixing this would actually solve the the the the the the issue.

14:12 → 14:15

So the it would be UX, UI based,

14:15 → 14:20

maybe even copy can change the way users operate.

14:20 → 14:25

But it may be that those the same users don't want to sign

14:27 → 14:30

in to the platform just because it's so

14:31 → 14:35

the performance is so low that they are,

14:36 → 14:39

discouraged to to to use the platform.

14:39 → 14:41

And you can learn

14:42 → 14:45

in the data that, for instance, in ecommerce platform,

14:45 → 14:49

every fifty milliseconds of the delay will

14:49 → 14:52

decrease the amount of

14:53 → 14:55

items that you are going to sell.

14:55 → 14:56

So

14:57 → 15:01

still, it might be back end oriented.

15:01 → 15:04

It may be UI oriented. It may be front end oriented.

15:04 → 15:08

The ROI is the most important factor to

15:08 → 15:13

consider, and you need to work very closely with

15:13 → 15:15

the product owners to understand

15:15 → 15:18

the whole picture.

15:19 → 15:20

Yeah.

15:20 → 15:23

I would say don't ask this question in engineer because

15:23 → 15:27

then depending on what kind of engineer you

15:27 → 15:29

ask, you will get one of these answers.

15:29 → 15:33

Like, you know, you ask if a React developer and

15:33 → 15:38

if he sees, like, I don't know, view UI or whatever, he say, hey.

15:38 → 15:41

Let's let's refactor front end.

15:41 → 15:45

And the the the the situation goes on.

15:45 → 15:48

So definitely go to the business or a product owner

15:48 → 15:52

person and then work from there with the proper engineers

15:52 → 15:56

depending on the area that is in the spotlight.

15:56 → 15:57

Yeah.

15:57 → 16:02

Don't treat everything as an age just because you you are a hammer.

16:03 → 16:06

Alright then. Thank you very much.

16:06 → 16:11

One last question, and let's eventually try to make it short.

16:11 → 16:14

However, this is gonna be a tough one.

16:15 → 16:19

Sometimes we need to deal as a software vendor with,

16:19 → 16:23

I would say, divorce situation where we are taking over a

16:23 → 16:26

project from a previous vendor, and, obviously,

16:26 → 16:28

the previous vendor is unhappy with that situation.

16:28 → 16:30

What can we do?

16:30 → 16:33

What are the good practices to make it happen, like,

16:33 → 16:36

a gentle way, in a smooth way without any

16:36 → 16:40

obstruction and any sacrifice coming from the client?

16:42 → 16:47

I would say don't depend too much on them.

16:47 → 16:51

Like, make sure that you can reach your goals even

16:52 → 16:56

if the cooperation is

16:57 → 16:58

a a bit rough.

16:58 → 17:00

So this is one thing.

17:00 → 17:01

And, like,

17:02 → 17:06

a bit of diplomacy is never a bad thing, I would say.

17:06 → 17:09

So even if, like, the the the coach is rubbish,

17:09 → 17:12

it doesn't mean that they didn't do their best.

17:12 → 17:17

So, like, be be be kind and be be nice.

17:17 → 17:20

I would say be aware that they may

17:21 → 17:24

don't know how the system works.

17:24 → 17:27

Maybe they work in the company for a short time.

17:27 → 17:32

So this is still something that you need to you need to consider.

17:32 → 17:38

And I would say that the it's very important

17:38 → 17:42

to create transparent transition plan

17:42 → 17:44

and responsibilities

17:46 → 17:50

before the actual transition is going to happen.

17:50 → 17:55

A very important part that needs to be considered as well

17:55 → 17:58

are all of the manual process that the current

17:58 → 18:01

team is

18:03 → 18:04

do on the daily basis.

18:04 → 18:09

Very often, those processes, they are not documented.

18:09 → 18:12

They're not included into the code base,

18:12 → 18:17

but somehow they are important to maintain the system.

18:17 → 18:21

And this is very important to retrieve this information from

18:21 → 18:25

the current vendor because you won't be able to find

18:25 → 18:27

it anywhere else.

18:27 → 18:30

Gentlemen, I think this was a good interview.

18:30 → 18:31

It was very insightful one.

18:31 → 18:36

I think I hope that the people who are watching us will get

18:36 → 18:39

something for themselves, some words of advice,

18:39 → 18:42

something that they can use in their professional world.

18:42 → 18:46

Obviously, we encourage our viewers to ask questions.

18:46 → 18:50

You can drop us an outline via email, on LinkedIn,

18:50 → 18:51

using our social media.

18:51 → 18:53

Feel free to drop comments.

18:53 → 18:56

We are super happy to provide encourage and to provide

18:56 → 19:00

knowledge on the topics that are

19:00 → 19:02

important to you.

19:02 → 19:05

This was Merixstudio It's Time to Talk Show.

19:05 → 19:07

My name is Mike Lisewski.

19:07 → 19:10

Thank you very much, and have a great day. Thank you. Bye.

19:10 → 19:10

Thank you.

19:10 → 19:12

Thank you so much.