One Solution for Developer Fatigue

When you hear the words "developer fatigue," what images come to mind? Your team leader talking about yet another project with an impossible deadline? Bleary-eyed teammates on all-night coding sessions? Too much java (and Java)? Or maybe you see a more profound enervation brought on by the "the constant and increasing flood of new languages, libraries, frameworks, platforms, and programming models that are garnering popular attention in the developer community." Those are JNBridge CTO Wayne Citrin's words, soon to appear in a company blog post.

Citrin and other industry watchers have noted the growing frustration among developers faced with a constant need to learn and adjust to new languages and technologies while remaining productive. Citrin believes he has at least a partial solution to this problem, and I talked with him about it recently.

"It's great that there's so much innovation going on," he said, "but the half-life of many of these innovations seems to be decreasing. It used to be that something would come out, and once it got adopted, you'd expect it to be the big paradigm for at least a few years. That's just not the case anymore. It can be a genuine hassle to keep up with all this stuff, and it takes away from the time people need to be productive. At some point, people just start throwing up their hands."

JNBridge is a provider of interoperability tools for connecting Java and .NET frameworks. The company's flagship product, JNBridgePro, is a general purpose Java/.NET interoperability tool designed to bridge anything Java to .NET, and vice versa. The tool allows developers to access the entire API from either platform.

Citrin's solution, not surprisingly, lies in tools like JNBridgePro.

"It's a little self-serving on our part, I admit, but it's also true that interop tools can really help," he said. "They make it possible for you to introduce yourself to new technologies gradually, focusing on the things in those technology that can help you solve your immediate problems. If you're a developer who uses our stuff and you're deep into both Java and .NET and you need to make use of, say, Python or Groovy, you can reach out for features from those technologies at your own pace."

By taking it slowly and integrating features from the new tech into your projects as they need them, devs can leverage their existing skills, reduce the risk of making a bad bet, and reduce their stress -- which ultimately reduces developer fatigue, he said.

"As long as the implementation is Java- or .NET-based, we can help developers integrate any part of it into their existing project, when they're ready, and without having to throw all the existing stuff away, and completely learning the new thing, re-implementing it from scratch, and having to find and fix new bugs," he said. "It beats the heck out of the alternative of 'warehousing,' which is essentially jumping in and learning a new technology for its own sake."

Citrin isn't the only one noticing this phenomenon, of course. A lively back-and-forth on the consequences of these seemingly never ending demands on developers was sparked last July when front-end and server-side developer Ed Finkler (aka funkatron) wrote a blog post entitled "The Developer's Dystopian Future." In that post he confessed that his "tolerance for learning curves" was growing smaller every day.

"New technologies, once exciting for the sake of newness, now seem like hassles," he wrote. "I'm less and less tolerant of hokey marketing filled with superlatives. I value stability and clarity." He also expressed what is almost certainly a widespread fear in this increasingly polyglot world of simply being left behind.

Finkler's post struck a nerve in more than a few developers and fellow bloggers. Tim Bray, one of the creators of the XML specification, talked about it in his "Discouraged Developer" blog.

"[T]here is a real cost to this continuous widening of the base of knowledge a developer has to have to remain relevant," he wrote. One of today's buzzwords is "full-stack developer." Which sounds good, but there's a little guy in the back of my mind screaming 'You mean I have to know Gradle internals and ListView failure modes and NSManagedObject quirks and Ember containers and the Actor model and what interface{} means in Go and Docker support variation in Cloud providers?' Color me suspicious."

Programmer/podcaster Marco Arment took up Finkler's commentary in his blog.

"I feel the same way," he wrote, "and it's one of the reasons I've lost almost all interest in being a web developer. The client-side app world is much more stable, favoring deep knowledge of infrequent changes over the constant barrage of new, not necessarily better but at least different technologies, libraries, frameworks, techniques, and methodologies that burden professional web development."

Author Matt Gemmel commented on Arment and Finkler's posts on his "Confessions of an ex-developer" blog. "There's a chill wind blowing, isn't there? I know we don't talk about it much, and that you're crossing your fingers and knocking on wood right now, but you do know what I mean," he wrote.

Redmonk analyst Stephen O'Grady noticed Arment's, Bray's, Finkler's, and Gemmell's posts and wrote about them on his "tecosystems" blog.

"Developers have historically had an insatiable appetite for new technology," he wrote, "but it could be that we're approaching the too-much-of-a-good-thing stage. In which case, the logical outcome will be a gradual slowing of fragmentation followed by gradual consolidation." (Be sure to check out his new O'Reilly book, The New Kingmakers: How Developers Conquered the World.)

If you haven't already, it's worth reading these connected blogs. (I'd start with Finkler's.) And keep an eye out for Citrin's upcoming post on the JNBridge Web site.

Posted by John K. Waters on February 9, 2015