Hubristic Architecture

27 Jun 18 21:28 -0500

Hubris is not only annoying, it’s dangerous for the business.

Warning

The following comes from years of experience working with architects, and even doing a little architecture work myself. I am pulling this from those years of experience to list out what will certainly not work. Other traits and means will work to varying degrees and are largely dependent on the architect and the culture of the organization.

Qualities(?) of the hubristic architect

1. YAGNI

The hubristic architect is quick to throw this one out there:

Ya Ain’t Gonna Need It

The problem with ya ain’t gonna need it is that that ya ain’t gonna need it…until you do. It’s often (somewhat legitimately) used as reason to not work on the frivolous or unnecessary, but many times it can be a mark of short-sightedness or ignorance.

For instance, when a seasoned developer tells an architect that they want to add debug logging around a new component and that architect responds with “YAGNI”, that’s hubris. There’s a reason that seasoned developer has been around for a while - they’ve seen a thing or two. They know that adding additional logging to a brand new component 1) at worst will cause a minor (and probably unnoticeable) performance hit, 2) at best reveal that nothing’s wrong, or 3) most likely will show some shortcoming of the system.

A good test of when it’s appropriate to judge for YAGNI is with respect to scope. If YAGNI is being tossed out there at the code line level, it’s probably hubris. When it’s tossed out there when determining if you need a CDN for a two-user site, then there may be a case - but you should at least talk it out.

Side note

A good architect will always assume that the person they are talking to knows something that they don’t, or has the good sense to listen to that person if they have a decent amount of experience.

2. Codification of anything

Every {language,framework,software,methodology} has holes. Bias is bad.

There is actually overlap to the spirit behind #1 in that hubristic architects get tunnel vision and think they know better. A “here’s how Company X does it and don’t you dare look elsewhere for answers” is never a good sign.

I’ve seen this before with frameworks mostly: “we’re a JBoss/Drupal/Node shop”. Never mind that there may be a better framework out there. And who knows if there is unless the time and effort is taken to discover whether or not it’s a great fit? Exploration is key. The hubristic architect will never, ever look beyond what they already know.

3. Checking the boxes

An architect shouldn’t live to check the boxes.

A good architect will push the norms of the organization. Just because “we’ve never used that language here” doesn’t mean that you shouldn’t (but it does mean that close examination is necessary). A good architect will be open to outside suggestions and influences and not work in a silo that only accepts X or Y or Z. This is very similar to point #2.

The hubristic architect will only do what has been done before, presumably because they knew better in the past. The hubristic architect will only ensure that the minimum according to the book gets done, and nothing more.

4. Not thinking in abstractions

Monoliths are bad, mmmkay?. Everyone knows this, but there are still some out there that attempt to peddle this notion just wrapped in different words: “singular experience”, “single page app” (the wrong way), “holistic”, etc. They may attempt to fool even themselves into other notions by their language alone.

But overthinking in abstractions can lead to monoliths.

Composite microservices are a great, timely example of this overthinking: a service that pulls user information, blog post information, connection/friend information, comments, and other various and sundry services are wrapped in the very thing you’re attempting to get away from - the monolith.

The good architect will have a feel of when to break things up. And if not, he/she’s certainly willing to talk it out. The hubristic architect will not only not listen to engineering’s desires and demands to decouple or glue, but will insist on the opposite of what’s obvious.

5. Hoarding your knowledge

Beyond the bus factor: you’re just being a jerk. Overlaps with RDD (resume driven development).

The hubristic architect will not communicate, train, document, or otherwise show others how they work. Even down to code level (a very unfortunate position to be in, assuming they even code).

The good architect will share everything to the point of being nearly annoying. Blog posts, lunch and learns, participating in Slack threads: this all leads up to knowledge being shared across the organization and, or at the very least, reassuring the engineering community that you are thinking about the same problems. This includes things that aren’t even close to being ready for testing not to mention hallway usability testing or staging.

6. The Quiet Desparation

Are You Leading a Life of Quiet Desperation?

To steal from Thoreau: overcompensation (for past work), or living in the past and other misplaced values. This also overlaps with #5.

Sometimes people (and yes, you can lump architects into this group) must justify their existence. The justification may be to anyone, including themselves. A good architect will find ways to contribute, ways to make the company or organization successful. They will write code, work in the NOC, answer customer complaints: it doesn’t matter. The good architect will know and fully believe that the product that they are delivering is a reflection of them.

A hubristic architect will rely on past endeavours for furthering their career, and will refuse to work with front line personnel in handling calls and customer complaints. The hubristic architect will never, ever hand out their personal (and sometimes even work) cell phone number. This individual will decide that no goal is worth wasting their time on.

7. The Big Reveal

This extends to not communicating the research you’re doing for future work. Similar to #5 (Hoarding your knowledge).

The Big Reveal hubristic architect is one that works quietly, sometimes for years, in the dark or under the radar until one day they’re able to reveal the Big Secret Plans that they’ve toiled on for years. Only to discover that the business has passed them by, and that the engineering capabilities have passed them by, and that they’re stuck left holding a big bag of useless bits that no one wants, but in their head they’re some sort of technical rock star.

The good architect communicates, plainly and in open air, their endeavors and thoughts. Code leaks out bit by little bit for all to see, to criticize and question, and with which to test. The good architect isn’t showy but almost expects everyone else within the organization to at least heard of their project because (if they’ve done their job) they’ve shown it in the past prior to release.

8. Never writes code. Ever. And if they do, it’s bad.

And probably can’t read it either. And changing the copyright date in the footer doesn’t qualify.

This is the worst of all hubristic architects. They come down from on high with dictates in hand explaining to you, the engineer, how to do your job. But they haven’t written a line of code in years and if they have it’s been of such petty and miniscule consequence that any second day intern with half a brain could have written it better with more coherent commit messages.

The good architect commits frequently, and with quality. They may not be experts in algorithmic design but they know enough to question (and to be questioned), and recognize their shortcomings yet are always willing to learn better ways of doing things. The good architect will comment openly on pull requests and even submit their own.