Maintaining a large scale project. (Theory thread, no code.)

April 21, 2023

TL;DR

What is the best way to plan maintenance?

How do you think maintenance tasks should be planned?

What goes into maintenance aside from fixing bugs?

How much change should a program have when going into maintenance mode?

Do programs go into maintenance because we just want to fix bugs or are they going to be developed until the end of time?

How do you communicate between teams and applications to fix/make adjustments?

How do you being new people to a team to do maintenance?

How do you bring a novice programmer up to speed properly to do work? (Assume basic programming syntax knowledge. Not advanced.)

Long:

I'm learning more about "real" software development and we talked about documentation 4 years ago, we talked about all kinds of "how do we get into programming?" And "how do we plan a software project?"

Now, with the cumulative great expertise this forum has, we can look at program maintenance. John carmack (generally recognized as one of the best programmers) has been stating that programs are no longer "just being developed" and that most modern programs are going to enter a long maintenance period.

It's unlikely we'll see a Facebook 2.

From the perspective of the people "actually doing the work," many of you work in these realities. You've seen some good, you've seen some bad, you possibly have ideals of what would work better or worse.

Can you plan for maintenance?

If you are already in maintenance mode, is it too late to plan? What can you plan?

Should you write documentation?

Is it too futile to document anything because the code might change?

If you know a project inside and out, that's no issue for you to fix things and get them working.

But not everyone might know the project inside and out.

How do you plan out the work?

Maybe you don't know the project inside and out. Is there anything you do to plan what should be done or how it should be done?

What should you do besides fix bugs?

Yeah, if $6.83 shows up appropriately but $4,300 shows up as $.43 you need to fix that bug. But is there more going into maintenance?

How much should a program be allowed to change? Should you let a program change in such a way?

Do you see programs going into maintenance just to fix bugs or do you see programs go into maintenance because the company wants it to live forever?

Should programs be maintained until we see 4 people ride horses?

How can you best communicate between teams for optimal maintenance?

What methods and techniques help communicate?

Say for example you have a website and the server is made independently from the client team... Pretending it makes sense to not integrate both teams into one team. What helps make sure the teams can do what they need to do?

What directly hurts the information getting where it needs to go? Even if it seems like it would be beneficial to do said technique.

You need to expand your team. As a mid to senior level dev, how do you help people get to grips with your program so they can work effectively and do appropriate maintenance?

Should people have an understanding of the program in its workings or just focus on the part they were told to do?

How do you bring an associate programmer up to speed vs a mid vs a senior level programmer?

Can you stop or slow development to onboard people? Should you stop or slow development to onboard people?

Who should onboard people?

Should people be onboarded?

Can most anyone work in your project or do people need certain skills to get onboarded appropriately?

If someone struggles to do the work assigned, is that the fault of the new team member or the leadership and why?

Remixt · April 21, 2023

I don't have the time to bring insight into every topic in this thread, but as someone who has hopped in and out of large code bases fairly regularly I have found that bringing a new coder up to speed is never easy but the best way to do this is a combination of trivial tickets and pair programming.

1. Teach your ticketing system (I.E. JIRA) to them.

2. Walk them through a trivial ticket (like changing the text in a tooltip or something similar)

3. Observe them take a trivial ticket to completion, and if they get through it with little to no issues, assign a few trivial tickets for them to complete on their own.

4. Increase complexity slowly over time until they are familiar enough with the code base to take on most things.

5. Depending on the size and complexity of the code base, this could take 2 to 6 months.

Pair programming is a great way to speed up the process, and I assume if you have a huge code base then you have enough engineers to consider pair programming. I've always noticed a higher productivity and knowledge base in teams that utilize this.

Franck · April 21, 2023

2 hours ago, fpo said:

What is the best way to plan maintenance?

On large project it's always in maintenance mode. Those are you sprints, issues, whatever you call them

2 hours ago, fpo said:

How do you think maintenance tasks should be planned?

Usually it's come down to 5 steps

1 - Issue reported

2 - Issue evaluated

3 - Issue assigned

4 - Issue fixed

5 - Fix released

2 hours ago, fpo said:

What goes into maintenance aside from fixing bugs?

Just to name a few : optimization, database cleanup, structural changes, log evaluation, security assessment.

2 hours ago, fpo said:

How much change should a program have when going into maintenance mode?

I don't see value in a metric of that sort. If a program need change or fix it need to be the one it needs.

2 hours ago, fpo said:

Do programs go into maintenance because we just want to fix bugs or are they going to be developed until the end of time?

This is program per program basis. Some large programs do basic tasks and well so they get little to no fix. Others have daily even multi-daily changes needed.

2 hours ago, fpo said:

How do you communicate between teams and applications to fix/make adjustments?

Issue tracking, Emails, Teams...

3 hours ago, fpo said:

How do you being new people to a team to do maintenance?

New people on large project will not be confortable with doing fix and stuff until a long time. I know some apps that are still difficult to navigate with 3 years experience with it.

Under agile the lead should be able to attribute task correctly according to his resource (programmer) ability to complete X point per day.

3 hours ago, fpo said:

How do you bring a novice programmer up to speed properly to do work? (Assume basic programming syntax knowledge. Not advanced.)

Again this is case per case. Some large app are very well written and a week or two of training/mentoring can easily be enough. Others like mentioned above could take years to taking by the hand the novice

Marginalia · April 21, 2023

Pretty hard to give concrete answers.

All these questions have different answers depending on the size and the lifecycle of the project.

A ten or a hundred person corporation will work differently from e.g. Microsoft's Windows division.

As for what is maintenance in a mature project, addressing technical debt is probably the biggest one. Depending on your language, library churn can be another one.