Paul W. Homer

Java may have been called the next COBOL, but that’s not necessarily a bad thing.

COBOL has been an incredibly successful technology. Reliable, consistent, and easy to read, it has been the workhorse of the Information Age, managing the bulk of the world’s mission-critical systems. If the syntax requires lots of extra typing, that is offset by the sheer number of readers that have had to ponder its behavior.

Trendy software stacks sound cool—and, as most are quite immature, there is always plenty to learn—but the world needs reliable industrial-strength software to function. A new clever idiom or slightly obfuscated paradigm can be great fun to play with, but by definition they are shrouded in unknowns. We’re obsessed with finding some magical way to just snap our fingers and will the next enterprise-class system into existence, but we keep forgetting that over three decades ago Frederick Brooks Jr. said those kinds of magic bullets—silver or otherwise—just can’t exist.

We don’t need the next trendy toy to solve real problems for people. We need to put in the thinking and the work to fully understand and codify reliable solutions. Systems that only work on sunny days, or that need to be rewritten every year or so, don’t satisfy our growing needs for managing the complexities of modern society. It doesn’t matter how it works if it is unpredictable when it fails. Instead, we have to fully encapsulate our knowledge into reliable, reusable, recomposable components, leveraging them for as long as possible to keep up with the chaotic nature of our current period in history. If the code doesn’t last, it probably wasn’t worth writing.

Java is a great technology for this purpose: new enough to contain modern language features, but mature enough to be trustworthy. We’ve gotten better at organizing large codebases well, and there is a great enough wealth of supporting products, tools, and ecosystems to shift the focus back to real business problems and away from the purely technical ones. It’s a strong stack for decoupling the systems from their environments, yet standard enough to find experienced staff. If it isn’t the talk of the town, it is at least a very reliable, stable platform on which to build systems that last for decades, and that, it seems, is what we both want and need for our current development efforts.

Fashion should not dictate engineering. Software development is a discipline of knowledge and organization. If you don’t know how the parts will behave, you can’t ensure that the whole will behave. If the solution is unreliable, then it really just adds to the problem rather than solving it. It may be fun just to toss together some code that kinda works, but it is only professional if we build stuff that can withstand reality and keep humming along.