yep, the compromise is probably to separate maintenance from creative tasks, and accept that maintenance tasks need replaceable components, but then again, mayb

yep, the compromise is probably to separate maintenance from creative tasks, and accept that maintenance tasks need replaceable components, but then again, maybe it's ok to accept things like having a certain software component written by a "lone wolf eccentric genius" in a dialect of lisp he alone can understand (replace with your fav equivalent phrase) as the price for having really unique features and performance for that component that no competitor can match, and make contingencies for the risk of having to throw away that codebase and rewrite from scratch if he gets hit by a bus... maybe if the APIs and interfaces are properly designed (or processes or however else you may call then in peopleware land), you can accept working with unique and not easily replaceable components and somehow design systems that are architected to embrace the "hit by a bus" type of risks ...and if I think further along these line, the organization that can best afford these types of risks are big software corporations (think Google, Microsoft) that could afford to scrap entire codebases and projects (if they ever got over the "mind brakes" that make the managers consider such things insane), or start things in completely new directions when they bring new "genius visionaries" ...these types of innovation based on risky and irreplaceable components/people would be prohibitively expensive or impossible for start-ups, but may bring us new breakthroughs in things like general purpose AI or god know what ...maybe true progress really is the work of unique individuals and our whole focus on "team work" and "replaceable peopleware" is what suffocates and kills innovation