5 ms·

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

by nom 6y ago

Aperocky 6y ago
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.
- stevenwliao 6y ago
  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?
  - Aperocky 6y ago
    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.
  - Thrymr 6y ago
    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.
    - agakshat 6y ago
      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?
      - Aperocky 6y ago
        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.
      - Hallucinaut 6y ago
        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.
- Ididntdothis 6y ago
  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.
  - jmchuster 6y ago
    Oracle 12 lists 66 developers https://docs.oracle.com/database/121/REFRN/title.htm https://docs.oracle.com/database/121/REFRN/title.htm
  - deleted 6y ago
    [deleted]
deleted 6y ago
[deleted]
ardy42 6y ago
> 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.

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

by nom 6y ago

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

Aperocky 6y ago

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.

stevenwliao 6y ago
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?
- Aperocky 6y ago
  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.
- Thrymr 6y ago
  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.
  - agakshat 6y ago
    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?
    - Aperocky 6y ago
      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.
    - Hallucinaut 6y ago
      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.
Ididntdothis 6y ago
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.
- jmchuster 6y ago
  Oracle 12 lists 66 developers https://docs.oracle.com/database/121/REFRN/title.htm https://docs.oracle.com/database/121/REFRN/title.htm
- deleted 6y ago
  [deleted]

deleted 6y ago

[deleted]

ardy42 6y ago

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