Comment by twobitshifter | Hacker News Reader

Comment by twobitshifter | Hacker News Reader

Parent Full thread

Has anyone taken over a project from a departed developer? What were the steps that you took? I would wager most people will reach for the full rewrite which we know is something that you should never do. https://www.joelonsoftware.com/2000/04/06/things-you-should-...

However, many senior developers recoil at the thought of quality documentation and prefer “self documenting” code which doesn’t cover the why and thought process behind the code. This makes something other than a full rewrite daunting. Even with the best self documenting code you will continue to be surprised in large projects. The full rewrite allows the rewriter to reexperience the process but it’s very expensive and may be worse than the starting point.

If science and engineering were done like software, so much knowledge would be lost. We know that there are giants in the space of Science, Einstein’s work was published and continued on by others to this day. I think the difference is that in science the motivation is to learn and teach, whereas in software people are pressed to create almost exclusively. We won’t publish papers, but to get closer to science, I think it’s necessary for solo developers to keep a development journal as has been done by scientists for some time.

I mention nuts and bolts engineering, because in engineering, the best are usually mentoring others, catching mistakes, and teaching rather than actually doing the legwork. That’s an alternative angle to fight the bus factor.

Many times (not departed as in departed, just - not there any more).

Could of hard-won experiences:

- under no ciscumstances should you do the rewrite until you understand the whole domain, which is not until you know the codebase inside-out. And even then it's probably a very bad idea ("Yes but the old version allowed us to do X...").

- start with business requirements: make sure you understand what people expect from the system, how they use it, what it does at high level. Sit with users and watch them use the app!

- tests: do not touch the code until you understand the existing tests or, if tests do not exist, until you have covered the code with your own, preferably integration or end-to-end tests (unit tests are great, but they don't guard you against integration failures, which is what you want to be protected against here too)

- skim the documentation if it exists, but don't put too much faith in it as it is probably out of date. Same for comments.

- slowly start fixing bugs, cleaning up some code... whatever you do, make sure it is covered with tests.

- good luck. :)

Yes, multiple times. And this can happen at a well managed company. To some extent it's my niche. I'm not a coder (I program, but don't touch our product code base), but an industrial scientist, and these projects often involve multiple disciplines such as mechanical and electrical as well as code. My process is to start by just trying to figure out the theory of operation, and identify what is usually a single critical path of data through the code.

Right now I'm looking at a relatively small code base that was written by an engineer in the embedded systems team. The original authors are retired. It's generously documented, and a pleasure to read. This makes my life easier, but also less of a hassle for the un-retired engineers on the receiving end of my requests for help. I don't know about commercial coding, but adding comments and documentation can help a non-specialist work their way through code if they have some decent programming background.

The full re-write can happen if the departed developer is an entire departed business, e.g., an acquired company comes with code that is obfuscated to the point of being Goedel-undecidable ;-)

Science isn't flawless. There's the so called reproducibility crisis. I think what helps science is that nothing of lasting value depends on a single critical path from data to results, but is reinforced by looking at things from multiple angles. For instance we'd still trust general relativity had the Eddington experiment never happened. And scientists such as myself are always looking for ways to make our own work more open and reproducible. In my work, Jupyter Notebook has been a game changer.

Yes, I did multiple times. I had not done full rewrite, because there was zero reason to do it. Nor time for that matter. The thing I took over was typically developed over a lot of time, doing it again would take a lot of time again.

> However, many senior developers recoil at the thought of quality documentation

There is no such a thing as quality documentation. An individual here and there is able and willing to write one. Average developer is not. And I don't even blame them, it is in fact skill and job occupation on itself to be able to do so.

Developers are not even trained in how to write good documentation. There are no processes to check, test and review documentation.

Reply on news.ycombinator.com