Tech Decisions with Zenn Diagrams
Tags: techstack, programming, architecture, evangelism
Published: 2020-06-26 01:14:36

Here's another one of those I-shouldn't-have-to-write-this articles.  In the past, I've ranted about tech evangelists and mindless fanboys.  But if we strip out some of my bombastic terminology, what I'm really fighting against (hopelessly) is the emotional and illogical process we often undertake when we endeavor to assess new technologies.

To aid in this age-old tech quandary, I'm introducing a radical new tool:  I call it a _Zenn Diagram_.  

[NOTE: If you think these diagrams look an awful-lot like those silly things called "Venn diagrams", I assure you this is nothing of the sort.  Venn diagrams are old and stooopid.  You don't wanna be stooopid, _do you_??]
<br/>

## The Problem

Unless you've only been coding for a few months, you've probably had this experience:  

Your team is using some Gnarly Old Stable Technology (GOST).  It's not without its faults.  But it _works_.  Just as importantly, you're well-versed in GOST.  Your entire team has solid experience with GOST.  If you're being honest with yourself, you probably _like_ GOST.

Then something _new_ comes along - a Glorious New Awesome Technology (GNAT).  Because you're at least somewhat aware of "industry trends" and you try to keep abreast of new advancements when they suit you, you've _heard_ of GNAT.  Heck, you've probably even downloaded the NPM GNAT package and played around with it in your local environment.  You may have even heard some "thought leader" singing its praises at a recent convention - or watched an engrossing video about it on YouTube.  But you didn't see anything so earth-shattering that you felt the need to adopt it into your own projects.

But you probably don't work alone as a renegade dev.  You've probably got other team members, and some of them may be genuinely _excited(!)_ about GNAT.  They start talking about it at work.  They start pushing for it every time you need to spin up a new feature.  They start sneering dismissively any time someone recommends writing more code with GOST.  If they've really caught the "bug", they may even be agitating to _rewrite_ some-or-all of the legacy code using GNAT.

This is the moment when things can get... _uncomfortable_.  You're no Luddite.  You genuinely _want_ to be open to new techniques.  But you've been around the block enough to know that "new" is not always "better".  But once that GNAT starts buzzing around your dev team, it can be hard to squash it.  And in the back of your mind, you're not even sure if you _should_ be trying to squash it.

But if you simply ignore a GNAT, it rarely just goes away on its own.  Even worse, the longer you deny the presence of the GNAT, the more likely it is that other team members will start seeing you as a GOST - some stodgy, old, close-minded codger desperately clinging to the tools you learned when we were all using _dial-up_.

Thankfully, there are logical ways to address this conundrum.  Specifically, a good Zenn Diagram can help to remove the emotion from the debate and help GOSTs _and_ GNATs assess the technology based upon empirical factors.

Let's look at some common Zenn Diagrams:
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/pgocpqjlzjapogu8wzqp.png)
## The Flavor-of-the-Month Diagram

Cynics might scoff at this diagram.  Surely, any _new_ technology won't offer _less_ functionality than its predecessor, _right_?? 

Umm...

Granted, the diagram above is probably relatively rare.  The developers of GNAT certainly _thought_ they were giving us some kind of "new" functionality.  But I _have_ seen scenarios where the new "flavor of the month" offered no real improvement whatsoever, while _abandoning_ key features of the GOST.  In these scenarios, the drive toward GNAT is typically based on broader industry trends, where GOST uses some kinda "ugly" pattern, and GNAT complies with the hot, cool, new pattern.  

In this kinda tech debate, it _should_ be relatively simple to present a reasoned argument that, while GNAT may indeed feel "cool", it's not practical to even consider abandoning GOST.  I say "should" because you can never fully account for the power of _fanboys_ who've glommed onto GNAT and simply won't let go.

If you're facing this kinda Zenn Diagram, and the rest of your team _still_ wants to jump to GNAT, you might seriously want to consider a new gig.  Even if you can choke down your disgust, it's only a matter of time before _this_ GNAT is challenged by yet another, _newer_ GNAT, and then you'll be going through the cycle all over again.

Although this situation may seem rare - _unthinkable_, even - I've found that foolhardy decisions like this _can_ be made on teams that simply have too much freedom (yes, that _can_ be a thing) or too much time on their hands.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/o9x7oze36sqylmrvkddj.png)
## The Trend-Chasing Diagram

As stated above, it's relatively rare to find a GNAT that offers _no_ new benefits, while orphaning a huge chunk of the GOST's benefits.  However, I don't personally feel it's at all rare to run into a situation like the Zenn Diagram shown above.

In this scenario, there's not much that you did with GOST that you can't also do with GNAT.  So that's a huge argument in favor of GNAT, _right_??

Well... _maybe_.

The problem is that there's not much that you can do with GNAT that you couldn't _already do_ with GOST.  In other words, switching to GNAT is mostly an exercise in chasing trends.

For example, imagine that functional programming is your GOST.  And at the latest big programming conference, some charismatic rebel introduced an exciting new paradigm - _conceptual programming_.  He even announced an entirely-new language called ConceptScript (CS) that enforces all the core tenets of conceptual programming.  

Some of your colleagues attended this conference and _whoa boy!_ are they excited!  Functional programming is suddenly stooopid. Conceptual programming is suddenly the only way to write applications faster and _bug-free_!  

You're genuinely curious, so you spend a good bit of time investigating this bold new "conceptual programming" technique.  But the more you look at it, the more it seems like CP is doing nearly all the things you've been doing - _for years_ - with functional programming.

Even worse, the more you inspect CP's core features, the more you find yourself thinking that this isn't a "better" way to do FP.  It's just a _different_ way to do everything you're _already doing_ in FP.  

These kinda Zenn Diagrams occur at the onset of foundational shifts.  For example: moving from OOP to FP.  There's not _any single thing_ that you can do with FP that you _can't_ do with OOP.  Conversely, there's not _any single thing_ that you can do with OOP that you _can't_ do with FP.  And yet, over time, one gains favor - and one gets relegated to the "stodgy old guy" bin.

These diagrams can lead to some of the nastiest Holy Wars - because they tend to occur when entire industry-wide practices are _evolving_.  Is FP "better" than OOP?  I tend to think so.  But anyone who's thinking even somewhat rationally about it will probably admit that OOP isn't inherently "wrong" and FP isn't inherently "right".  They're just two (fundamentally) different approaches to solving the same problem. 

In the hypothetical I gave above, should you suddenly _drop_ all of your FP development to embrace a radical departure to "conceptual programming"?  The answer is a clear and unequivocal:

_Probably_ not - but keep your eye on the trends.

Just by looking at the Zenn Diagram above, it would appear that the latest GNAT offers few improvements at the price of massive time-and-effort for new training and, in some cases, rewriting existing tech.  Then again, such tectonic shifts _do_ occur.  And when they do, you don't wanna be left as one of the last shops still cranking out GOST code.

The clearest advice I can give is to hold the line (for awhile, at least).  When the changes do not provide clear-and-immediate benefits, you probably don't wanna be on the bleeding edge of that trend - especially because some of these trends _fizzle out_.  

But you don't want to become a programming dinosaur, either.  Even if GNAT offers few tactical advantages, but the trend is sweeping through the industry, there _can_ be a solid business case for, eventually, switching to the GNAT.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/bzjfr3nts9l0sy73dlvl.png)
## The Bigger-Better Diagram

Some technologies truly offer everything we had with their predecessor - _plus a huge buncha cool stuff!_  That would seem to be a pretty clear win for the GNAT, _right_??

Umm... _maybe_.

In this diagram, it's clear that GNAT offers a good deal _more_ functionality, while sacrificing almost none of the GOST functionality.  But it can be foolhardy to evaluate this diagram based on nothing more than the net _difference_.  

For example:  Let's imagine that GNAT now allows us to `makeToast()`.  And it allows us to `makeJelly()`.  And it provides a native `HipsterToastCafe` primitive that allows us to spin up cutting-edge, over-priced, artisinal applications with little-to-no effort.  So that settles it, right?  I mean, why _wouldn't_ you switch to GNAT??

Well... just because the GNAT provides new tools, and just because it (theoretically) supports our stodgy old GOST tools, doesn't _necessarily_ mean that it's worth making the switch.  If you've never before had a need to `makeToast()` and you couldn't care less about `makeJelly()` and you can't imagine how you'd possibly use the `HipsterToastCafe` primitive, then it's entirely possible that adopting the GNAT will be a massive waste of time and money (and if you're not keeping score at home, time _is_ money).

Like the Trend-Chasing Diagram above, it's entirely possible that, at some point in the future, you might find yourself migrating to the GNAT.  You might end up doing this, even though you have no desire whatsoever for that magical `makeToast()` method.  But switching is not a trivial matter.  

And if you can't see an immediate benefit from the GNAT's (supposedly) revolutionary features, there's nothing wrong with sticking to your guns for awhile and arguing in favor of the GOST.  Even if that makes you look like a relic.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/1baghvs1v3rlad6zl7je.png)
## The Trade-Off Diagram

If all parties are being honest about the decision (and... they rarely are), the diagram _usually_ looks more like the one above.  That's because advancements are usually _incremental_.  The GNAT often allows us to do _most_ of the things we could do with GOST.  Similarly, the GNAT _usually_ provides a handful of intriguing new features.  It also typically orphans at least _some_ of our beloved GOST features - or it ports them over in a manner that is painful for those who've grown accustomed to GOST.  

So how do we evaluate this kind of diagram?

1. Look carefully at the features that are _supposedly_ shared by both.  When a new technology is introduced, its purveyors will typically claim that you can do nearly _all_ of the things that you could do in the old technology.  But just because there's _some way_ to do the same thing, doesn't mean that it's _desirable_, or even _feasible_.<br/>

1. Be honest about the "new" GNAT features.  Just because they're "new" doesn't necessarily mean that you _need_ them - or that you even _want_ them.<br/>

1. Be honest about any old GOST features that are being orphaned.  In my experience, the GNAT fanboys will dismissively scoff and claim that you don't _need_ those old features anyway.  They get so caught up in the glory of their GNAT, that they downplay anything you could previously do with GOST.  (NOTE:  If you're advocating for the GNAT, and you feel tempted to brand the GOST's lost functionality as silly or unnecessary, this is a fabulous way to identify yourself _as a douchebag_.)<br/><br/>

IMHO, decisions like these are harmed by evangelistic ravings - on _either_ side.  And they're aided by honest investigation by _all_ parties.  Don't cling stubbornly to the GOST.  Don't squeal with glee any time anyone even _mentions_ the GNAT.  Don't get all snotty just because someone has a hard time seeing the benefits of GNAT, or professes their preference for GOST.

Assuming that the "shared" functionality in the center of the Zenn Diagram is _truly_ available in _both_ solutions, it's helpful to ask everyone some hard questions like:

1. What are we _gaining_ with the GNAT?  Is it really a critical improvement?  Or is it just... _new_?<br/>

1. What are we _losing_ with the GOST?  How painful will it be to craft GNAT equivalents?  How does this affect legacy systems?  Is it possible to do a wholesale _migration_ (unlikely).  Or will this lead to some indeterminate period (probably, _years_) where we're forced to support both GOST _and_ GNAT solutions?<br/><br/>

## Mitigating Factors

I've made a lotta vague references to things like "features" and "functionality".  But it's _critical_ to remember that this is rarely based simply upon the features that are baked into any particular technology.  In other words, in a "perfect" analysis, the Zenn Diagram should account for **_ALL THE THINGS!!!_**

For example, let's consider the Trade-Off Diagram from above.  If those circles represent nothing but the raw functionality of the competing technologies, then that diagram is not very helpful at all.  

Imagine that you're truly considering a switch to that hot new "conceptual programming" paradigm - and the associated ConceptScript language - that many of your devs are raving about.  Let's also imagine that you sat down and did a deep dive on all of the inherent _features_ of CS compared to that old, funky JS that your team's been using for years.  

At the end of this analysis, you've found that CS really does provide some _cool_ new features that you just can't get in JS.  CS allows you to do _most_ of what you were already doing in JS.  Furthermore, you've determined that anything you're _losing_ from JS really isn't that big'ah deal.  

So it's settled.  You should switch to ConceptScript, post haste, _right_??

Not so fast...

If you've got a dozen experienced devs on the team, and they all have years of expertise with JS, and they all have _zero_ expertise with CS, then that GOST circle should probably be a bit bigger.  

If you've got a million lines of legacy JavaScript code that's humming along in production with no major maintenance headaches, that GOST circle should probably be growing even bigger.

If the marketplace for new JS devs is massive - and the marketplace for new CS devs is... _nearly nonexistent_, that GOST circle should continue growing.  

If you rarely get the chance to spin up true "green fields" projects, and all of your "new" dev will just be adding/expanding features in the legacy JS codebase, that GNAT circle should be shrinking.

In fact, even if all the _tangible_ features of the languages are properly taken into account, and even if the GNAT seems to be a true "net positive", you may still find that your Zenn Diagram looks like this after taking into account all the broader factors from your team and your environment:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/w4amssekr2w38ogro2dl.png)
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/b2jq3pb4bm1rw20zm9ru.jpg)
## Dooood... _Really_???

You may be thinking, "This dude just cranked out several thousand words in a programming blog to talk to us about... _Venn diagrams_??"
<br/>

> No!  They're _Zenn_ Diagrams!

<br/>Seriously, though.  I realize that a Venn diagram isn't exactly a revolutionary new idea.  Personally, I don't care if you never utter the words "Zenn Diagram" again.

What I _do_ care about is the fact that, far too often, we base these decisions on _emotional_ factors.  Or we base them on flimsy anecdotal evidence.  

Dick worked on a TypeScript project in 2013 that was an absolute nightmare.  So now he tries to shout down anyone who dares to even _suggest_ TS in any future projects.

Dick follows this guy called "Thaught Laider" on TikTok.  And Thaught swears that functional programming is dead and conceptual programming is the wave of the future.  So now, Dick simply won't shut up about it.

Dick desperately wants to tinker with NestJS.  So now he makes snide little comments under his breath any time we spin up a new Express endpoint.

Don't be a Dick.