Monkeynoodle.Org

In theory you “need” to pick between dependency hell or bloated monoliths, but in practice you don’t actually have to pick and so everyone uses a mixture of both and then complains about the problem set they’re feeling most acutely right now: Microservices

Same goes for opinionated user experience versus highly configurable user experience. The pendulum swings hard to one side, but that reintroduces problems… and fixing them undoes the momentum toward a perfect implementation. For instance, we might want a firm opinionated UX design for the colors used in the product.

Oh, the time wasted in company after company, trying to recreate the wheel and find a reporting color palette that isn’t too egregiously awful for the several types of color-blindness that exist. After some weeks, the designer will finally acknowledge they can’t get to perfect, so the options are:

1. stop trying to sell to the United States government or European Union customers (hint: that’s not really an option unless your company is still tiny). It used to be that ADA (Americans with Disabilities Act) didn’t mention colorblindness, but more recently larger customers demand WCAG (Web Content Accessibility Guidelines) compliance. You might ask: as an accessibility issue, isn’t it the moral thing to do? Well yeah, but corners get cut all over. Also, how do any sales happen to the EU and USG since so many products fail to meet this bar? Fun fact, customers can bypass compliance for things that they really want to buy. They have to fill out a form that says “we looked at alternatives that were compliant and they sucked, and $vendor solemnly swears they’re aware of this and will fix it real soon now.” This has to be refiled with every renewal until the product meets standards, so it’s painful for everyone and a good barrier to remove, but not impermeable. So really this option is “accept greater difficulty in selling to the Feds and Europeans”.
2. toss in a color customization picker so the individual user can pick colors for each datapoint — this ends in tears as each panel of each report uses a slightly different shade of blue, so the next release will probably…
3. embrace palette customization so the individual user can select entire color palettes that they can see. You might do this at the customer level instead of the user level, that’s generally fine. You only include three or four that the designer likes of course.

In the absence of experienced leadership or institutional memory, vendors will speedrun those three steps in order instead of starting at the final position: develop a single palette design, realize it violates WCAG and ADA, give too much customization, then switch to the ability to select from prebuilt palettes. A couple of hackathons later, some one restores the ability to make custom palettes and the crowd goes wild.

That’s the situation with something more visible to the average user, but it’s even worse (slower cycles, more productivity loss) in development fashion. I won’t waste everyone’s time talking about build pipelines or integrated development environments or languages, those are hardly areas of expertise for me. I do feel comfortable writing about dependencies versus monoliths though.

Dependency Hell is the loving phrase to indicate that the thing you want to do relies on a specific version of another thing being present. You want to run a vulnerability scanner? It’s written in a specific version of Java or Python, it’s got bitness and path expectations, it probably needs specific optional libraries to do some tests. You want to play a game? Need drivers for your video card, and the latest one introduced a bug for customers using your brand of motherboard. You wrote content for an scripting language but the language is starting a new incompatible major version? You need to pin to the old one until you can get around to upgrading or rewriting in another language. In systems that are first built then configured, such as your laptop, dependency hell is the law of the land.

Bloated Monoliths are the solution to that problem — everything brings everything it needs. Statically-linked binaries, containers, virtual machines, appliances, datacenters-in-a-box. This works so well that it’s spawned a complete reboot of the monitoring industry (with a few weird offshoots as well): no one knows what’s happening inside the monolith, and the system is made of monoliths stacked on top of each other inside a trenchcoat, with a lot of other systems doing automatic things in response to their internal state models… pretty fun troubleshooting what’s happening. In systems that are configured first and then built for deployment, the bloated monolith is king.

What’s really neat is that this pattern exists wherever there is a handoff between people’s responsibilities, in a lovely echo of Conway’s Law. How is the source code structured, as a single file or in lots of separate libraries, classes, modules, or packages? How is it stored in source code control, as a million separate repositories or in one grand monorepo? Are the components tested individually or in bundles or perhaps not until the field gets to touch it? Hundreds of little pendulums, swinging from chaos to control and back again. Remember, if we didn’t swing the pendulums then we would have to focus on meaningful work instead, it would be a lot harder on everyone.

Okay, so both sides suck, for different reasons… and you don’t really have to select one or the other, nor can you, because whichever one you prefer, you’re still dependent on and supporting the other kind all over the place. Nevertheless, the drive to switch back and forth persists, and can even be considered healthy if you twist your head just right: because it makes developers and administrators continually re-engage with the system’s design. Swinging the pendulum is a rather pointless exercise if you look for outcomes like “we’ve solved software packaging”, but in making everyone regularly review design and refactor the system, it recreates the mental model freshness that allows for efficiency and reliability improvements. It’s like syntax linting, but at a level that engages architecture thinking instead of rote repetition. Those don’t come from making a choice, but rather from rereading and rewriting what already exists, and the fashionable swings of the pendulums are there to inspire and justify those rewrites.