12 ms·

The problem I have with the argument is that "improvement" needs to be something objective and measurable. "I'm throwing away old code because eww" isn't improv

by qsort 2y ago

The problem I have with the argument is that "improvement" needs to be something objective and measurable. "I'm throwing away old code because eww" isn't improvement. The two examples cited are very telling: > Consider cases like introducing Kotlin to gradually level-up a Java shop. But why? Introducing a second language to do pretty much the same thing is a giant leap in complexity and it's not obvious we'd get something real in return. > What about a PostgreSQL operation rewriting SQL stored procedures in PL/Python? Yet again, why? SQL is popular and very well understood, the alternative solution would be less portable and a rewrite would introduce unnecessary risk.

altdataseller 2y ago
Throwing away old code and rewriting it in a sexy, new language also takes time away from projects that are actually meaningfully innovative: ie projects that help customers do more, or be more efficient
Larrikin 2y ago
Kotlin became the language of Android, not because it was new, but because multiple company's studied it and devs were more productive in the language after a relatively short on ramping period, many cases a weekend to get familiar and less than a month to be more productive. Java was stagnating on Android as well and Kotlin was able to introduce a lot of modern features far more quickly. The only argument to keep with Java is that Java actually seems to be chasing after some of the gains Kotlin made.
- ktosobcy 2y ago
  > Kotlin became the language of Android, not because it was new, but because multiple company's studied it and devs were more productive in the language after a relatively short on ramping period, many cases a weekend to get familiar and less than a month to be more productive. [citation_needed] > Java was stagnating on Android as well and Kotlin was able to introduce a lot of modern features Java was stagnating on Android because Google was (and is) lagging with implementing newer features. Android 12 only got support for Java 11 ffs... Interestingly enough with Project Mainline it will be possible to support newer Java versions in Android…
avgDev 2y ago
I was let's rewrite this app guy once. I rewrote the whole app and realized that main issues were documentation and lack of understanding by anyone within the business how the system actually works. The new app is better, but if a new dev looked at the code base they would suggest a rewrite. I would want to do it too, but I just don't feel like joining that rodeo at the moment. This cycle will repeat till the end of time.
adamc 2y ago
Strongly agree with this. Software Engineering needs something equivalent to evidence-based-medicine. (I think it exists, but isn't as widespread as it should be.)
- vundercind 2y ago
  Business needs that. Everyone jumped on the data-driven train (how rigorous was the information that lead them to do that? LOL) but it’s top-to-bottom bullshit. We have almost no clue how to measure management efficacy, for instance, and the methods we do have are too fiddly and require large sample sizes in just the right circumstances, so nobody but academics even try. It’s like that for almost everything. You look at the data gathering behind and analysis methods for the median strategy PowerPoint and it’s just gibberish, completely useless nonsense, and it doesn’t exactly take a trained & practicing scientist to tell, but everyone who can spot these things and is on the management track knows they’re not supposed to point that out. It’s all a big, weird game of pretend.
  - adamc 2y ago
    I don't agree at all. This is the McNamara fallacy applied to software. You don't have to measure management efficacy. When you call for rewriting project X in technology Y, this is, at a first approximation, just saying: What reasons do we have for thinking this will make a difference? What evidence exists to support such contentions? You don't need to be able to perfectly measure things to have evidence. Evidence might be "We used Y in this other project because <it was good in some way>, and the engineers seem to be able to make changes faster: here's our data." Or "Technology Y is better at <some feature> because it <has more mature libraries, or a better approach to concurrency, or whatever>, so we think it will benefit us." You don't have to be able to measure everything perfectly to make better decisions.
    - vundercind 2y ago
      I agree! The current approach needs “science-based management” because that’s what it’s play-acting at—that’s what it would take to do the thing they’re claiming to do. I think it’d be much better to admit that’s far too expensive and/or nearly impossible, plus probably not something most executives are interested in doing anyway, and back off the whole hyper-“legibility” (bad-)data-based-everything notion. It’s an expensive drag mostly delivering bullshit.

by qsort 2y ago

altdataseller 2y ago

Throwing away old code and rewriting it in a sexy, new language also takes time away from projects that are actually meaningfully innovative: ie projects that help customers do more, or be more efficient

Larrikin 2y ago

Kotlin became the language of Android, not because it was new, but because multiple company's studied it and devs were more productive in the language after a relatively short on ramping period, many cases a weekend to get familiar and less than a month to be more productive. Java was stagnating on Android as well and Kotlin was able to introduce a lot of modern features far more quickly. The only argument to keep with Java is that Java actually seems to be chasing after some of the gains Kotlin made.

ktosobcy 2y ago
> Kotlin became the language of Android, not because it was new, but because multiple company's studied it and devs were more productive in the language after a relatively short on ramping period, many cases a weekend to get familiar and less than a month to be more productive. [citation_needed] > Java was stagnating on Android as well and Kotlin was able to introduce a lot of modern features Java was stagnating on Android because Google was (and is) lagging with implementing newer features. Android 12 only got support for Java 11 ffs... Interestingly enough with Project Mainline it will be possible to support newer Java versions in Android…

avgDev 2y ago

I was let's rewrite this app guy once. I rewrote the whole app and realized that main issues were documentation and lack of understanding by anyone within the business how the system actually works. The new app is better, but if a new dev looked at the code base they would suggest a rewrite. I would want to do it too, but I just don't feel like joining that rodeo at the moment. This cycle will repeat till the end of time.

adamc 2y ago

Strongly agree with this. Software Engineering needs something equivalent to evidence-based-medicine. (I think it exists, but isn't as widespread as it should be.)

vundercind 2y ago
Business needs that. Everyone jumped on the data-driven train (how rigorous was the information that lead them to do that? LOL) but it’s top-to-bottom bullshit. We have almost no clue how to measure management efficacy, for instance, and the methods we do have are too fiddly and require large sample sizes in just the right circumstances, so nobody but academics even try. It’s like that for almost everything. You look at the data gathering behind and analysis methods for the median strategy PowerPoint and it’s just gibberish, completely useless nonsense, and it doesn’t exactly take a trained & practicing scientist to tell, but everyone who can spot these things and is on the management track knows they’re not supposed to point that out. It’s all a big, weird game of pretend.
- adamc 2y ago
  I don't agree at all. This is the McNamara fallacy applied to software. You don't have to measure management efficacy. When you call for rewriting project X in technology Y, this is, at a first approximation, just saying: What reasons do we have for thinking this will make a difference? What evidence exists to support such contentions? You don't need to be able to perfectly measure things to have evidence. Evidence might be "We used Y in this other project because <it was good in some way>, and the engineers seem to be able to make changes faster: here's our data." Or "Technology Y is better at <some feature> because it <has more mature libraries, or a better approach to concurrency, or whatever>, so we think it will benefit us." You don't have to be able to measure everything perfectly to make better decisions.
  - vundercind 2y ago
    I agree! The current approach needs “science-based management” because that’s what it’s play-acting at—that’s what it would take to do the thing they’re claiming to do. I think it’d be much better to admit that’s far too expensive and/or nearly impossible, plus probably not something most executives are interested in doing anyway, and back off the whole hyper-“legibility” (bad-)data-based-everything notion. It’s an expensive drag mostly delivering bullshit.