4 ms·

This is an analogy, used in communication with non-engineers. As such the analogy is valuable not for its accuracy to us, but to the people we are speaking to.

This is an analogy, used in communication with non-engineers. As such the analogy is valuable not for its accuracy to us, but to the people we are speaking to. If you tell someone about "clutter" in the code, to the other person that sounds like a failing, something that should be avoided, something that we should just do better at. And something landing at the feet of the engineers to deal with, because it's their fault to begin with. Whereas the concept we are trying to get across is: we have accepted some things that are less than ideal (code quality) in order to gain in another area (probably time to release). A tradeoff, and more importantly a tradeoff driven by concerns outside of engineering's domain. I might agree that the term is overplayed and watered down, but any replacement has to include the role that the business side plays in the problem.

benibela 5y ago
As analogy one could go for updating to bigger and better. Like, when we were a small company we were delivering our stuff with metaphoric bicycles, because they are cheap and good for the environment. Then we updated to motorbikes for faster delivery. Now our customer base has grown, and we have a lot more stuff, so we are updating everything to trucks, and need time to dispose the bikes that we do not need anymore. Then finally, we have become an international company and need to update to cargo planes. And when they try to blame the engineers that it is their fault and they should have been using the biggest thing from the beginning, you can say: You do not buy a 747 to deliver stuff to you neighbor on the same street.