

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

Dear $Community<p>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?<p>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?<p>---<p>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).<p>To help you to answer my question I will try to explain my scenario as follow:<p>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.<p>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.<p>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.<p>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.<p>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?
======
arien
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.

------
pixeloution
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.

