4 ms·

I think there is even more going on. - Adding is a repeatable, comfortable process whereas removing tends to require more individual approach. - Adding tends

I think there is even more going on. - Adding is a repeatable, comfortable process whereas removing tends to require more individual approach. - Adding tends to be stressed a lot in corporate environment, whereas you don't hear your managers demanding to remove features. - Adding is usually easier to explain whereas explaining how removing functionality improves the system requires more effort on both sides. - Most people treat code as asset. Which is completely backwards way to think about it. I think about the code as liability. If your mental model of code as an equivalent of an asset, the most natural way to improve value of the system is to add more code to it. - Most techniques you read up on the Internet are aimed at adding brand new code, not at removing it.

ptidhomme 6y ago
This is pretty much my experience. People tend to perceive every piece of code as valuable, however useless or stupid it may be, because of the time and money involved. Until the codebase gets so crippled that you hear the goto solution from these same people : complete rewrite.
- lmilcin 6y ago
  Aaaaand that is another can of worms. I have recently had a potential client come to me to help them rewrite an old Java application. They have already been unsuccessful rewriting it once, now the want "somebody with more experience" to do this "the right way". So I ask them, "What is wrong with your old app?". Them: "Let's not focus on it, we are interested in how you plan the new one" Me: "No, really, I need to know what is the problem with the old app. Please, humor me." Them: "It is Java 1.6" Me: "Okay, but what is wrong with the app?" Them: "We need to upgrade to at least Java 11." Me: "And how about that app, what is wrong with it?" Them: "We are being chased by our security for at least past couple years. The problem with the app is that it uses old libraries that cannot be upgraded because of old Java. We tried to upgrade the Java but failed so we want to start with clean slate" Me: "But what is wrong with the app? I mean... if you have been unsuccessful upgrading Java that surely means there is some kind of underlying structural problem?" Them: "Yeah, we also have a lot of failed transactions but that is because of old libraries." Me: "Surely, you don't want to say that back when Java 1.6 was new it was not possible to write reliable applications?" Them: ... Me: "Also, why your previous rewrite failed?" Them: "That's simple, the developers were not up to the task." Me: "But who managed those developers?" Them: ... Me: "That's right. Last question, how did you decide to rewrite the application if you don't know what is the problem with the previous one?" Them: "What do you mean?" Me: "No, thank you, I learned everything I needed. Goodbye"

ptidhomme 6y ago

This is pretty much my experience. People tend to perceive every piece of code as valuable, however useless or stupid it may be, because of the time and money involved. Until the codebase gets so crippled that you hear the goto solution from these same people : complete rewrite.

lmilcin 6y ago
Aaaaand that is another can of worms. I have recently had a potential client come to me to help them rewrite an old Java application. They have already been unsuccessful rewriting it once, now the want "somebody with more experience" to do this "the right way". So I ask them, "What is wrong with your old app?". Them: "Let's not focus on it, we are interested in how you plan the new one" Me: "No, really, I need to know what is the problem with the old app. Please, humor me." Them: "It is Java 1.6" Me: "Okay, but what is wrong with the app?" Them: "We need to upgrade to at least Java 11." Me: "And how about that app, what is wrong with it?" Them: "We are being chased by our security for at least past couple years. The problem with the app is that it uses old libraries that cannot be upgraded because of old Java. We tried to upgrade the Java but failed so we want to start with clean slate" Me: "But what is wrong with the app? I mean... if you have been unsuccessful upgrading Java that surely means there is some kind of underlying structural problem?" Them: "Yeah, we also have a lot of failed transactions but that is because of old libraries." Me: "Surely, you don't want to say that back when Java 1.6 was new it was not possible to write reliable applications?" Them: ... Me: "Also, why your previous rewrite failed?" Them: "That's simple, the developers were not up to the task." Me: "But who managed those developers?" Them: ... Me: "That's right. Last question, how did you decide to rewrite the application if you don't know what is the problem with the previous one?" Them: "What do you mean?" Me: "No, thank you, I learned everything I needed. Goodbye"