Don’t Dunk on Languages

The perennial internet discourse like “Nobody should use Java in ${CURRENT_YEAR}” and “We re-wrote everything in Rust” is an interesting one. At the end of the day, it’s a pointless discussion and harkens back to the editor wars for the quality of discourse and progress made.

Nuance the Orange Site Lacks

Remember that when you’re reading discussions about frameworks on your favorite content aggregator, people are largely commenting without knowing the whole story behind decisions made to adopt a framework or language. There are often business reasons for a framework being adopted.

This should be intuitive, but if we believed and adopted every idea about how software development should work, we’d be nailing jello to a wall: nothing would ever get done. It’s a side effect of the innovation produced in the software industry - as new advances in computing are made, new paradigms and tools are developed to make use of these advances.

In the professional sense, balancing business needs and resources is critical to making a product. Perhaps an “MVP” in Rails or Express makes sense to get something shipped to start with. You’re at the point where you need to rely on both what you know, and what third-party libraries (or, “the ecosystem”) can get you from “zero to one”.

The technical debt you incur will eventually come to bite you with scale, both in the sense of daily active users and as a function of how large your development org is.

It’s far more interesting in my mind to evaluate choices from a cohesive, unified “re-write” or “2.0” version of a software stack.

These choices tend to evolve from “We wrote it in Python because it worked” to “We’ve found these rough edges in the stack, and this is how we want to move forward.”

It’s a pity, yet understandable, how some decisions behind frameworks and development paradigms aren’t publicly shared.

Spoiler Alert: Java is Alive and Well

There’s a place for many of the “hated” languages in real, shipping software development these days. Facebook had PHP expertise, so they wrote parts of their stack in a language derived from it. Netflix and Amazon have Java expertise, so they make a solid internal platform and tooling to maximize productivity while abstracting some of the minutae. Google doubled down on protobuf, and found that having a shared way to call other services eliminates overhead. And that C++ was hard to get folks onboarded to, so we got Golang.

None of this is particularly proprietary knowledge. Look at job postings for your favorite matured tech company, or even your favorite FAANG. There are job postings for Java, Python, C++, and probably even .NET. The business has grown to the point where there’s a blessed way to build things internally, and the health of the platform (read: hopefully reduced operational and developer overhead) has created “A Way” of doing things. Choosing that “Way” of doing things is a complex decision that I can’t realistically provide a “silver bullet” answer to, because every business situation is unique. The method of critical thinking and self-questioning while weighing the options is unfortunately something you learn over time by doing it and seeing what happens.

Don’t Cowboy

That doesn’t mean there isn’t room for continuous growth by questioning the way things are done and experimenting. If we all accepted the current status quo of how things are done, we wouldn’t be able to grow as an industry or come up with different ways of solving a problem.

Having said that, there’s little point in doing something “your own way” without qualifying it with some good reasons. An existing “80%” solve might get you most of the way there much quicker. The other 20% is a balance of tradeoffs - some of which can be worked around, and some of which might not be possible given your design constraints.

Balancing when to go against the grain and do something different should be nuanced and based on measurable data.

Sometimes when reading articles around migration, I feel that the discussions lack depth or “Scientific Integrity,” as Richard Feynmann posits it. I’m sure there’s more to it than what people let on about. As mentioned above, I’d like to see the followup to see the fallout of the decision that was made. That kind of discussion would be far more productive to advance people making better decisions.

Measure the Outcome

Some articles give pretty good examples with measurable evidence of how their technical decisions measured up. It’s refreshing to read posts like these.

In other posts, companies share the pitfalls around business decisions (shared databases, in this case), and how they learned from their decisions in the past. Even in Java.

What makes these decisions solid is that they’re trying to measure something specific. Though there’s certainly internal nuance and “another side of the story” that isn’t told along with unstated “table stakes” around the environment they were made on, they focus on something measurable and a goal in mind. Asking “What problem are we trying to solve?” is critical to prevent bikeshedding and the equivalent of “editor wars” around software development.

The Point?

Don’t be so quick to dunk on a choice of a language. There may be reasons behind a choice of language that you don’t necessarily have full context on.

Thinking critically about the context and reasoning behind the choice of language is far more interesting, and calling bullshit behind flawed decision making is far more interesting. Doing that with nuance and not looking like an asshole is a different story, though.