Hacker News Reader

Comment by cperciva | Hacker News Reader

Another reason for NIH: If something breaks, you have the in-house expertise necessary to figure out why.

Of course, this breaks down as soon as people leave the company -- but for an early startup where the founders are expected to stick around, it's much faster to get something fixed if the author is within arm's reach.

View on HN

This works the other way round too. For many companies, if something breaks they want a support contract in place with agreed SLAs.

The threat that a crucial back office system might break and the only people they could call to fix it are Ray and Moss from the IT dept in the basement, is worth paying a premium to avoid.

For many companies, if something breaks they want a support contract in place with agreed SLAs.

And here, in a nutshell, we have the difference between a startup and a large corporation.

If you have sound documentation and design methodologies, then even if someone leaves, you should be in good share.

Whether that's going to be the case is another question, of course.

Documentation cannot really replace first-hand experience with code. That said, code without good documentation can puzzle even those who wrote it in the first place.

The same could be sade for outside code, it just needs to be documented properly and be well-designed.

Ideally the code produced by an organization with coding standards should be more accessible than good written to different standards. Whether that happens, of course, is another question.

This might be true in some rare cases, but in general I disagree with it.

The people who originally designed it, no matter how well documented, are much more likely to understand and be able to extend it. Tests help too, however losing your initial developers, if they were any good, will always have a high cost associated to it. You can get by sure, but it has a high cost. I think the difference in comprehension in pretty large.

I think there are a couple things which cause this difficulty: 1) I don't enjoy writing reams of documentation, and I bet most other developers don't either. 2) I don't enjoy reading reams of documentation before I can dig in, and again, I bet most other developers don't either.

This is why it's really important to do code reviews. Not just so that any egregious practices are eliminated before they are inflicted on the codebase, but also so that more than one person knows what's going on, and what the original intent was, with every piece of code in the codebase.

Reply on news.ycombinator.com