like so many things written about software, this ignores everything in the process that isn't a computer program. Future-proofing is a natural consequence of a

like so many things written about software, this ignores everything in the process that isn't a computer program. Future-proofing is a natural consequence of a management style that doesn't clearly set goals and boundaries. Engineers wind up future-proofing because their goalposts are constantly moved. Picture this scenario: Engineer: I can build it in different ways. This simple way will accommodate N users, this more complicated way will accommodate M users but will take three times as long. I recommend we do the first option, because it's unlikely we'll see more than N users. Management: no, we want to get to M users, build it the second way That sort of situation is exceedingly common. The reality is that the vast majority of engineers don't get to set the product development road map based entirely on engineering concerns.