Skip to main content

Linnoedge

Your Software Works. But Can Someone Else Maintain It?

Your Software Works. But Can Someone Else Maintain It?

A software project isn’t truly successful just because it works.

A better question is: If the person who built it leaves tomorrow, can someone else continue to maintain and improve it?

People change roles. They move to new projects. Sometimes, they leave the company. That’s a normal part of any business. We can’t always control what happens in people’s lives, but we can control how well a team prepares for those changes.

For a software company, this is especially important because knowledge can easily become concentrated in one person.

When One Person Knows Everything

Imagine your company has been using a system for several years. It works well, your employees use it every day, and your business depends on it. But there is one person who knows almost everything about it. They know why certain things work the way they do, where to look when something goes wrong, how to release a new version, and what needs to be considered when adding a new feature.

Whenever there is a problem, everyone says, “Ask him. He knows.”

Then one day, that person leaves.

The software is still there. The source code is still there. But a large part of the knowledge about the software may leave with the person.

This is where a working system can suddenly become a difficult system to maintain.

Working Software vs. Maintainable Software

These two things are not the same.

Working software means it does what it is supposed to do today. Maintainable software means the team can understand, fix, and improve it tomorrow.

Working vs. maintainable Working software Does what it is supposed to do today Maintainable software The team can understand, fix, and improve it tomorrow

For example, adding a new feature might normally take three days. But if nobody understands how the existing system works, the same feature could take two weeks, simply because the team needs to spend the first week figuring out what is already there.

We wrote about the gap between estimates and real progress in Estimate and Schedule: Why Developers Need to Take Ownership of Their Progress.

That hidden cost can become a real problem for both the development team and the customer. It is one reason system development needs to consider long-term ownership, not only the first release.

What We Do at Linnoedge

At Linnoedge, we know that people may leave, even when we don’t want them to.

We genuinely care about our members and always try to support them. But sometimes, life has another plan. When that happens, our responsibility is to make sure their departure doesn’t create unnecessary problems for the customer or the team.

That’s why we have a handover process for people leaving a project or the company.

It’s not simply: “Please tell someone what you were working on.”

We use a checklist to make sure important areas are covered, including current tasks, project information, important knowledge, documentation, and anything else the next person needs to continue the work.

We also arrange knowledge-transfer sessions with the people taking over the work. When appropriate, these sessions are recorded so the team can come back and review them later when a question comes up.

Handover at Linnoedge 1. Check with a checklist Tasks, project info, knowledge, docs 2. Knowledge-transfer sessions With the people taking over 3. Record when appropriate The team can review it later Knowledge stays with the team

The goal is simple: the knowledge should stay with the team, not leave with the person.

This is closely connected to making tacit knowledge available across a team, so that important context can be carried forward instead of remaining with one specialist.

What This Means for Our Customers

For our customers, a professional development process should provide more than just working software.

It should provide continuity, transparency, and confidence.

When someone changes projects or leaves the company, our customers shouldn’t have to worry about starting over. The knowledge, documentation, and project context should already be part of the team and the process.

This also makes it easier for us to onboard new members, respond to changes, and keep projects moving without unnecessary disruption.

More importantly, it means our customers are not relying on a single individual to keep their software running.

They are relying on a team, supported by a professional process.

That is an important difference.

If you are on the buying side, you can ask your development partner the same four things:

  • Can someone other than the main developer explain why the system is built the way it is?
  • Does someone else know where to look when something goes wrong?
  • Does someone else know how to release a new version?
  • Does someone else know what needs to be considered when adding a new feature?

We wrote more about what a vendor is really promising in What Does a Software Vendor Actually Sell?

At Linnoedge, we believe quality is not only about how well we develop software. It’s also about how we manage the people, knowledge, and processes behind it.

Our goal is to make software development more stable, predictable, and sustainable for our customers, even when people and circumstances change.

Have a software project in mind? Let’s talk about how we can help.

Because when you work with Linnoedge, we want you to feel confident that your project is supported not by just one person, but by a team and a process built to keep moving forward.

Frequently Asked Questions

What is key-person dependency in software?

It is when one person alone knows why the system is built the way it is, where to look when something goes wrong, how to release a new version, and what to consider when adding a feature. It stays invisible while the system runs well. It shows up when that person changes roles or leaves.

What happens to software maintenance when the developer leaves?

The software and the source code are still there. But if the knowledge was not handed over, changes can take longer, because the team first has to figure out what is already there. At Linnoedge, we have a handover process with a checklist and knowledge-transfer sessions for members leaving a project or the company.

What should a software handover cover?

Our checklist covers current tasks, project information, important knowledge, and documentation. We also arrange knowledge-transfer sessions with the people taking over, and record them when appropriate so the team can review them later.

Tech Leader with 15 yrs in IT. Leading with a ‘what is right, not who’ mindset to deliver exceptional, client-first solutions.