That's what business leaders think.

Then you get to the critical component where you fire the lead architect/programmer and then it keeps working fine for few weeks, but you find more bugs and you need to upgrade/fix it. Only to find out the documentation if they exist don't help at all and the first 2 tries builds fine so you put it in production only to see everything destroyed. And after 1 year of back and forth you hire 10 other developer to maintain this thing and then 50 others to write a new one.

I bet the number of developers that are working on the business critical stuff is very low. Years ago I talked a lot to people at Oracle and Apple and it was always amazing how small the core development teams for the big products were.

Oracle 12 lists 66 developers https://docs.oracle.com/database/121/REFRN/title.htm

An architect that doesn't leave documentation and share knowledge isn't doing their job and management needs to get ahead of this. What if this "key person" decides to find another job?

Of course there's documentation, and also knowledge sharing, doesn't help he/she and 50% of his/her teammates are let go and without a solid way of knowledge transfer or the desire to do so under this context.

This is especially bad for software that are written under tight deadline - no matter how much document you write about it. And sadly, there's more software that are written like that than otherwise.

An architect that doesn't leave documentation and share knowledge might also be thinking about protecting his own job. Being irreplaceable is good job security.

I’ve always wondered, does this actually happen? People not getting fired because they are irreplaceable partly because of their own failure to document stuff?

Nobody except newcomers to the codebase look at documents on code structure, and of course no one is fired for not producing it/producing a crappy version of it.

When the newcomer can't get anything out of that doc, if it exist, he/she just need to ask the creator, who will explain very nicely how everything is done, and that newcomer become a code guru in that codebase, and the cycle continues.

Until you layoff 50% of the team and now suddenly nobody knows how 50% of the stuff work.

Very frequently in corporate environments, at least in investment banks I have known and heard of many people earning four figures a day pretty much purely because they've been allowed to carve their own niche that becomes indispensable.

Ironically, the worse they are (think 5000 lines of Perl with two functions) then the less viable it is to replace them.

> IMHO Unicorns are built with the assumption that almost every developer is replaceable. At that scale the critical knowledge is not with the developers.

Critical knowledge is with the developers unless:

1. The system is stable and feature-complete.

2. You've employed about 10 FTEs documenting every aspect of the thing.

If those two criteria aren't met, they system becomes tech debt, a larger risk, and will likely decay until replaced.