Ask HN: When a developer leaves a project, how do the project survive?

Dear $Community

What do software projects do when its key developer(s) leave a company or project, Is there any blogs or interesting write-ups about the problem and what solutions there to addressing the problem?

Also how important is it that the lead/key developer like the technology the software is written in, and can someone that does not no the platform or technology pick-up the project and maintain it?

---

I'm aware the above two question is easily influenced by the scenario of the project and company but I'm sure this is a general theme in big and small companies so any links or references would be appreciated, even keywords I must google for(Seeing I already tried and failed).

To help you to answer my question I will try to explain my scenario as follow:

I work for a small to medium sized company of about 150 people. A internal software project was started three years ago by two key people a Developer and Architect. After a year of development the business started to use it, and I joined the team six months later.

A Niche Software Development platform was chosen and in the beginning it gave the company a lot flexibility but after a year and a half we started to run into performance and maintenance problems large due to incorrect usage of the platform.

Recently the key developer left the company on good terms, but we are now left with only 50% of the mind share of the current system.

So we have a complex business system with more then 160 database tables, a really big hairy code base and the original person that developed the system is not available any more.

If I get carte blanche my first reaction is that we need to rewrite the system, but what will change when I leave the company in two years time?

2 comments

[ 3.2 ms ] story [ 14.0 ms ] thread

pixeloution 14y ago ↗

Reading code is almost always (much) harder then writing it. Learning you way around the existing code base, and refactoring it if necessary is (almost) always a better option then rewriting it.

In a rewrite you'll find your self relearning about edge cases already solved, you'll lose features and business requirements you didn't even know about. You'll end up with a more maintainable (for you) but worse product in most cases.

Going forward you should have good documentation for key things regarding your system. If its not part of someone's job now, you should explain to your boss(es) why it needs to be someone's job in the future. Documentation is not time poorly spent.

arien 14y ago ↗

There are various answers:

a) There should be no key developers, no indispensable people in your projects. This is often hard to achieve on small companies.

b) Communication: In a group of developers there should be good communication about ideas and functionality. Documentation helps a lot, but sometimes just sharing the basic reasoning behind a component is enough to carry on.

c) Adaptation: Provided there is a lack of a) and b), your team should be good enough to adapt and survive to such drawbacks.

Now, for your particular case (I believe you are in c)), consider what will be better for the company overall? What will take you less time or be better in the long term? Trying to understand the current code or writing it from scratch?

I wouldn't worry about what will happen when you leave the company in two years time, because whatever path you choose, you should follow a) and b) to prevent from this happening ever again. Write documentation, share your ideas with fellow developers or even team up with some for this project, don't take on it on your own.

Hope this helps.