3 ms·
At the same time, it also means collectively we don't know what we're doing to get where we're going and are just throwing stuff at a wall to see what sticks.
by partomniscient 6y ago
At the same time, it also means collectively we don't know what we're doing to get where we're going and are just throwing stuff at a wall to see what sticks.
It also made me think of the Apollo 13 movie.
The engineering/process people got the thing into space, the adaptable/dynamic solve it with 'gaffer-tape and whatever is laying around' people got the thing home.
We still need both approaches for different reasons.
“Personal survivor bias“ accidentally chooses a side for you.
Experience eventually makes one realise there aren't diametrically opposing sides, just different capabilities needed in different circumstances.
- p_l 6y agoExcept the people who did the "tape it together"? Those were the same people who made the long process before. That's why they could just tape it together, they were deep in the knowledge of the system they were fixing and thus could tape a kludge together to get them back.
- partomniscient 6y agoBut that's because in those days the people that built the thing have to do production support once it goes live. That doesn't happen so much in larger organisations because they have separate teams divided along "add/build something new" and "keep it going" boundaries without a lot of cross-pollination.
- p_l 6y agoThere's also the difference between building bottom up with full knowledge of what you built, like the Apollo program team had (even if they bought something externally, the people who made it were available to the team, and/or the team studied the items in depth). And then there's modern world of slapping together libraries that are often not known, sometimes with closed source, sometimes without real documentation. I've had to use disassembler in the past to access framework we were supposed to use...