Welcome to Sufficiently-Advanced Technology!

If you’re reading this there is a better than average chance that you either are an innovator or will be soon. People who regularly attend conferences, read widely, and follow obscure and longwinded blogs tend to skew venturesome; active information-seekers with diverse social groups and information sources, possess breadth of knowledge, are more willing to explore and adopt new ideas, and are able to cope with higher levels of uncertainty. If you are an innovator then, according to current research, you are part of a vanishingly small demographic that makes up just 2.5% of the total population. The unique cognitive and social diversity of this group offers perspective and insight into ideas, opportunities, possibilities, and solutions ahead of the mainstream.

Perhaps you see the solution to a problem right now. Congratulations, you have an idea–an innovation–that just might make a material difference in the lives of a lot of people. How do you get the other 97.5% of the population to adopt your solution? Will your innovation take off by itself on the merits of its benefits? Unlikely. If the best ideas always won, I wouldn’t be writing this. Even when the idea or innovation has clear and obvious advantages, skeptics must be won over. Old, entrenched habits must be abandoned. Innovations must be evaluated, explored and increasingly accepted until they reach critical mass (only then will they take off). This process can take years or may never succeed at all. Your efficacy as an innovator depends on your ability to optimize and streamline this process, influence your peers, and ultimately effect change in the real world. There is an art–and a science–to the diffusion of innovations.

Continue reading...

In part I we explored the history and goals of DevOps and the Agile movement and the motivations for maturing your DBOps practice. In other words, part I addresses “mindset.” Let’s now look at this in practice and get into the “how” of DbOps, addressing the remaining “skillset” and “toolset” topics. Most crucially this involves not only understanding the tools you’ll be working with but also understanding the database. Poorly planned database changes have the potential to cause extended unwanted downtime and, if they break compatibility with the previous version of your app, can complicate rollbacks. Knowledge of RDBMS internals is crucial to moving “offline-breaking” database changes (database changes that require downtime and break compatability with previous versions of code) to “online-compatible” changes (database changes that do not introduce downtime and can be remain backward/forward compatible with code changes).

Continue reading...

Everyone seems to want agility, and the DevOps movement has provided tools and practices to enable this. While the tools available today are wonderful, there remain unique challenges when it comes to delivering code changes that also include database changes.

I’ve been building database pipelines on-and-off for over 20 years now. The tools have may have changed but the core principles have not. It would be trivial to write a talk, essay or blog post that was just a tour of syntax and an entertaining summarization of the documentation. You don’t need me to read the docs only to regurgitate them for you into prose or PowerPoint. Instead, I’m going to take a holistic approach that encompasses mindset, skillset, and toolset. What I hope will make this work stand apart from similar content out there is I will be writing from the perspective of a (recovering) DBA and share vital insights that are more relevant than ever.

Continue reading...

This post picks up from part I which broadly tells the story of where we are currently and how we got here; ultimately introducing HTMX as the “third way.” It serves as the background and context for this post. If you haven’t already read it, go ahead… I’ll wait.

Now that the background is out of the way, let’s look in depth at HTMX. Rather than the usual quickstart or toy examples, we’ll be looking at this in the context of a real production application already in the wild. We’ll modernize a legacy MVC application, examining the UX without and then with HTMX.

Continue reading...

A.k.a Michael Cary - and all the other identities and aliases I have held in my life (fun fact, this might be the first time ever those two names have appeared side by side in public!). They’re all masks I’ve worn, idealized versions of myself that I want to present to the world and, ultimately, lies I’ve told myself (and possibly you).

“I’m not defined by what you see, I’m also all of the things you’ll never see.”

-Derek DelGuadio, In and Of Itself

I wrote something today, and felt moved to publish it somewhere. If you are one of the vanishingly few people who actually read my blog, it’s entirely possible you’re interested in getting to know not just my thoughts on tech, but perhaps also interested in getting to know me a little deeper as well.

Read on if you want to see some of the parts of me you have likely never seen. I’m exposing myself for a moment, “warts and all.” If not, no worries, more tech opinions and knowlege are already in the works.

Continue reading...

When I look back on my career in technology, I’ve been seduced, over and over again, by this idea that best practices exist and that I can consider my work “good” so long as I follow those best practices. In some ways it would be wonderful to work in a field where there are absolute “right” and “wrong” answers but I no longer believe software engineering is one of those fields. Every single decision we make has consequences and whether these consequences are positive, negative, or mixed will depend on the context. It’s all just a set of trade-offs, and the key to making good decisions lies in understanding what matters most and evaluating the trade-offs in this context.

There are no best practices, only trade-offs.

-First law of Software Architecture

We’ve somehow gotten into this weird place in web development where the consensus seems to be that an absolute set of best practices exist; where the only meaningful decisions surround which framework to use and how to find the optimal implementation details within that chosen framework. Unfortunately the web development space has become so myopically focused on frameworks, tooling, and Single-Page Applications (SPAs) as the de-facto “best practices” that the trade-offs of these approaches are rarely discussed–or even well-understood up front–and, in many cases, the result is an ocean of bloat and accidental complexity that often could have been avoided entirely.

Continue reading...

I have now been typing using the Dvorak keyboard layout longer than I have used QWERTY. It’s been over 15 years since I first switched and probably a decade since I moved to the even more niche Programmer Dvorak Layout. As the year winds down (and I am in currently in quarantine) I figure I’d take some of this idle time to write a little bit, and this is where my head is at today. Who knows, there may be some interesting take-aways from this. On the other hand, it may just be 1000-or-so words of “brain droppings” as George Carlin would say.

Continue reading...

Many developers strive for elegance efficiency in their code. Imagine a hypothetical developer who takes this too far. Perhaps this developer looks back in shame at the sloppy, inefficient implementations their much less experienced self had written. They were, undoubtedly and objectively, “bad.” Over time, their code grew cleaner and more efficient. They could measure progress in wall-clock time, algorithmic complexity, or other quality metrics. Somewhere, however, the pendulum swung too far. If their “bad” code was slow, and their “better” code is faster, it stands to reason that even faster is even better. They reached a point where they would squeeze out every spare microsecond at all costs. The result was difficult to read, change, and understand; perhaps “the juice was not worth the squeeze.”

Performance can be a valuable system capability, but only in context. Remember the “Mad Potter’s” wisdom on the difference between “a lot” and “enough.” Architecture trade-offs must be considered in many dimensional contexts. Never trade an excess of one capability for a deficit of a more important capability. That said, sometimes performance is among that short-list of business-critical capabilities–perhaps at the very top. What constraints induce high-performance at the architectural level? Read on to learn about the Space-Based Architecture.

Continue reading...

In our previous post we looked at a technically partitioned, coarse-grained, distributed architecture. Although that pattern balances capabilities like scalability and elasticity with low cost and simplicity, a domain-partitioned architecture may offer many advantages. For an organization with well-defined domains and domain-aligned teams, this next pattern offers a very balanced and pragmatic distributed architecture that offers comparable capabilities to an architecture like microservices at a fraction of the cost and complexity. In short, a Service-Based architecture offers a highly viable “middle-ground” between monoliths/n-tier architecture and microservices. This architecture can act as a stepping stone between monoliths and more complex topologies although often it will represent an acceptable and desirable end-state for green-field and legacy systems alike. Read on to learn about the Service-Based Architecture

Continue reading...

So far in this series on abstract styles we have only looked at monolithic abstract styles and a handful of defining constraints. In reality, however, much–in not most–of the systems we will design as architects will involve some kind of network component. Although many implementations of the layered monolith or modular monolith may be extended through the addition of the client-server constraint (and, typically, some type of API constraint) the next several posts will focus on abstract styles that are, at their core, natively distributed. We will start by examining the N-tier architecture.

Continue reading...