I wonder what practices that are considered reasonable or at least common and defensible today will be considered moribund and obsolete in a decade and what extreme minority practices today will be widespread in a decade.

We've seen quite a few practices come and go. A lot of people will say it's all basically fads, e.g., as when Alan Kay derisively says "programming is a pop culture" but, IMO, that's pretty obviously untrue and it's easy to name sweeping changes that are massive improvements.

One example of something that became semi-mainstream in a decade and very mainstream in two decades is https://mastodon.social/@danluu/110213144744259862. Another is the idea that you can and should be able to build code basically all the time, have CI, etc.

Brooks, writing in 1995, noted that someone from MS wrote him to say that MS can build once a day. Brooks considers that a positive development, but isn't sure it's worth it. He implies that it's reasonable to merge/build once a week.

People at a startup I worked for that was founded in 95 would've considered it laughable to build daily, let alone weekly (they built what would now be called CI infra to allow constant builds) while the world's premier programming thought leader presented once-a-week builds as reasonable.

There were a number of companies that ignored the thought leaders and instead implemented reasonable practices. These companies had a huge productivity advantage (https://mastodon.social/@danluu/110339234955028325). Another example is

MS vs. Google build practices not too long after Brooks noted his uncertainty that building daily was worth it.

MS improved their build system massively and went from being able to build once a day (on a good day — zero times on a bad day) to doing 8 builds a day: https://danluu.com/microsoft-culture/.

Meanwhile, Google built what you'd consider modern CI infra for a monorepo with that let people build at any time because it would've been considered absurd to only be able to build 8 times a day.

Another big one was using higher level languages. Steve Yegge has talked about how Geoworks wrote things in assembly and how they ended up getting destroyed by Microsoft in part because their performance was crap compared to MS (because it's very hard to make sense of 15M LOC of assembly).

When I was in college (early '00s), most people had moved past thinking that everyone should write assembly to thinking that everyone who was a serious programmer should write C or C++.

Joel Spolsky, the next big programming thought leader after the Brooks era, has an entire essay about how teaching people Java instead of C allows stupid programmers who couldn't hack it in C to get a degree.

At the time, you also often heard that real programmers didn't write "scripting languages" like perl/python/ruby/etc., at least not for serious code.

If you look at successful startups from just after Joel's anti-Java anti-HLL polemic, a lot of them were created on ruby or python.

Back to the original question of what tools/practices will become common in the next decade or two, looking at what did become common, the things I can think of were generally things that weren't really "sold".

No one at Centaur needed to be sold on CI or read about it from some thought leader. Compared to having daily or weekly builds, it was such an obviously huge win that people just built it without needing to be sold, and that goes for the other sweeping changes I can think of as well.

I'm sure there are counterexamples, but when I think about the things that have had legions of people selling them, like TDD, etc., these things haven't taken the world by storm in the same way.

Appealing to elitism seems to be another "success smell". A lot of old practices that got replaced by more effective ones appealed to elitism and lost. And new practices that appealed to elitism also haven't succeeded in the same way that CI, automated testing, etc., have.

An example of this would be the legions of people who claimed that FP or Lisp or both were secret weapons that would make you super productive or make your company successful because smart programmers use them and/or they're secret weapons for productivity (and, BTW, I like FP).

In the wake of the failure of FP to live up to these lofty promises, people moved the goalposts and claimed that FP was a big advantage, but there are other reasons companies are successful, FP still outperforms, etc.

A lot of the revised claims are basically that the tech side doesn't matter that much, so the huge FP advantage isn't apparent, but we've seen multiple waves where companies that don't adopt better technology get lapped and can only survive via other massive advantages, e.g., non low-level companies using "scripting languages" vs. C/C++ just after Joel's anti-HLL polemic, assembly in the Geoworks days, etc.

Contrary to the claims, FP is simply not in the same class of productivity gain.