Category: Processes

Content-Generating Machine – or, A Love Letter to Creating

Content-Generating Machine – or, A Love Letter to Creating

We’re generally good at generating content. We have been as long as we’ve been working together, it was one of the first amazing things we noticed when working as a team. Other people dread putting together a presentation, or writing up a blurb for a document, or crafting an email to get the right message across – we don’t really have problems with that. No big deal, nonchalant shrug.

We commonly refer to this ability we have as a “content-generating machine.” We can – and have! thanks, you-know-who-you-are and your content smashing emergencies – knock out 90 minute presentations in a few hours. Have something to say, put it down, and polish it until it’s beautiful. It helps that we talk about our content between the two of us, for a long time, before we get to the point of putting (metaphorical) pen to paper, but…still. It’s cool, this magical ability that we possess.

…unfortunately for this narrative, we haven’t published anything here in a long time, with the notable and exciting (to us!) exception of last week. That’s because having something to say isn’t enough. You have to have enough soul – perhaps more precisely soul energy – to create. And you have to have even more soul to share what you create in a public place. Take enough soul damage and…it gets progressively more difficult to share.

Having something to say isn’t enough – take enough soul damage, and it’s hard to share.

Creation, and Soul Bruises

I would follow the trail of this fabulous squirrel ANY-DAMN-WHERE. – L.

Creation requires soul because creation comes from the soul – any kind of creation. Writing (fiction or non-fiction), composing (lyrics or music), drawing, painting, sculpting, building, dancing… the best creative things are outpourings of our souls and their many many moods and feels. Creation is you – the core you that wants to be known and understood and also is super afraid of being alone because of who you really are.

Writing, at least the non-fiction kind that we do, takes thoughts that typically start as impressions and pictures and patterns that we see, and puts them into words in a sentence, and then a paragraph, and eventually an arc of something that’s hopefully interesting and ideally somehow meaningfully true for our audience. It requires paying attention to those thoughts, and weaving them into something that’s linear and logical. It also requires remembering the things that we wanted to talk about that were related, and knowing what’s a finite unit of “blog” or “talk” and what’s maybe a, uh, squirrel trail.

Writing, creating in general, also requires accepting that the thoughts you have, or the soul that you want to share, is worth something – that it’s worth the work of getting it out of your head at all, and also that it’s worth sharing. It takes love, and creativity, and storytelling, and vulnerability. And…if you’re as soul-bruised as we were at various points in the past year or so, well…souls can’t create if they’re beat up too badly. Not easily, anyway.

Creation, and Soul Healing

“The opposite of war isn’t peace – it’s creation.” (La Vie Boheme B, Rent)

The problem with creation requiring a healthy(ish) soul is that creation itself lets you heal. It lets you process your feels, and tell your story. Creation lets you heal the bruises and cuts and scrapes on your soul.

But the great thing about creating is that sometimes, the things that are created have the magical impact of helping other people heal, and process. And when you’re too soul-bruised to create yourself, you can heal in perhaps a less direct way than, say…sharing your soul on a blog.

Maybe it comes from switching to a more private kind of creating, or a different kind. Maybe you find other people’s songs that fit exactly what you’re going through, or maybe other people’s stories tie directly to your experiences – writing them, or reliving them by way of a great author.

Basically, you can heal, and grow, via creating, yes – but you can also heal, and grow, via experiencing other people’s creations.

How to Get Back to Creating

It’s okay. It will happen. 

That’s a thing that Laine worries about, a lot, whether her soul will…well, repair (no pun intended, hahaha) enough to have the capacity to create again. That worry is almost certainly a relic of 30+ years of untreated ADHD and feeling like getting her brain to DO the thing was a constant battle.

But…the fact is, it always comes back. When enough has healed, and enough time has passed for some brave to build back up, the drive to create always reappears. Not being alone, literally, helps a lot – as in, creating with someone else and getting that built in support and shared brave.

Be you, and have fun.

When you find you can create, when there’s enough room in your soul to be that core you again, it will just…flow. Your mind and your soul will line up, and everything just…knows what ideas connect where, like building up a Lego wall. If you can heal the damage, and you can get past the critics in your own head, and just… be you and have fun, creation is a wildly strong source of joy. You can let yourself be yourself, and worry about if it exactly “makes sense” or is “valid” later.

If you’re not bruised, beaten, scared of rejection, or simply tired, then creations just…appear out of nowhere.

We interact with a lot of people who don’t create, or who don’t share what they create, for a lot of reasons. If you fall into this camp, we’d strongly encourage you to think about why not, and if you like, send a message our way and tell us, or use us as guinea pigs to share what you create with a very controlled subset of “everyone.” We’d love to hear from you.

For us, once we’ve healed enough to want to create again, the “why not” is always fear – the same fear we see over and over as the core fear of everyone, the fear of being alone somehow. Bruises are just a hurt-reminder of that fear, whispering that maybe it’s really true, that fear that we’re alone…maybe it’s really true.

It’s not true. We promise. Life maybe has sucked, life maybe still sucks, but creation lets you deal with that. And actually dealing with stuff will leave you (has left us) much less alone.

Master Data Management Rant

Master Data Management Rant

Foreword by Laine:

If you’ll recall our post entitled, Go: a Grumpy Old Developer’s Review, you might remember that sometimes Josh goes on legitimately amazing rants about technology and architecture. HERE IS ONE, YOU ARE ALL WELCOME.


What is Master Data Management?

Master data management (MDM) is a method used to define and manage the critical data of an organization to provide, with data integration, a single point of reference.”

In other words, MDM tries to create a standard database schema loaded with uniform, processed, “cleaned” data. The data is easy to query, analyze, and use for all application operations. Sounds great!

Most business have a lot of data – and if they could access that data accurately, reliably, and rapidly, it would give them a lot of insight into what their world looks like and how it’s changing. They could unify their understanding of themselves, their customers, and their partners, and become more agile (agile as in, “able to change directions quickly in response to changing conditions,” not Agile as in the development methodology).

MDM is sold as a silver bullet that will enable this master view of data, this easy querying, and this agility. But I haven’t seen that actually happen very often.

MDM Kills Agility

MDM is a tool of consistency – and consistency forces things to exist in specific ways. The real problem with MDM is then reflected when you consider that the data of a business is like the mind of the business. Imagine if your mind could no longer consider something to be valid input unless it had seen it before – as in, you could understand when you found a new variety of orange, but if you had never seen a starfruit before, you literally could not comprehend it. As one of my colleagues said,

“Building a gold data model is like nailing jello to a tree.”

MDM in its traditional, monolith definition, kills agility. Basically, it’s building a perfect utopia in which all changes have to be agreed on by everyone, and no one can move in until it’s perfect, and then no one can change ever again. Our job as technologists is not to stagnate – it’s to “deliver business value at the speed of business” (Gitlab). Businesses need to move fast, and to do that they must be able to adapt – and if IT systems don’t adapt, then IT systems slow the business down

I’ve come across multi-year MDM projects full of ETL and data standardization meetings – and the business is finding data points that matter faster than they can be standardized. An MDM initiative that can’t move as fast as every other part of the business just slows it down, eats resources, and eventual dies a dusty death of forgottenness.

A Possible Solution: Jump-Start with a Purchased Model!

Often companies will sell a partial model of the business’s data that can be adopted more rapidly, which is typically “industry-standard” data – with claims that this will speed time to market for a MDM system. But it doesn’t.

Every organization sees the world slightly differently. This is a good thing.  Individual divisions and teams within each organization will also each see the world differently. These different views mean different schemas

Trying to fit everyone into one data model is like trying to make everyone speak exactly the same English, with no slang, no variations in tone or phrasing, and definitely no new words, connections, or ideas.

The perspective of a business, or any group, changes as the group learns and grows. Locking yourself into an old perception, or attempting to standardize via a process that takes years, is intentionally slowing down your business’s rate of adaptation and growth.

Also, it sets you up for years of arguments between teams that their view of the data – and by extension the world – is correct.

A Recommendation: Agility in Data Access Models, Not Data Storage Models

The need to have some kind of standardization so that a business’s data is useful is real. What we have seen work is more of a blended approach: spend 20% of the effort on making the data sane, and 80% of the effort on providing clear, accurate, scalable data access via APIs, in-memory databases, and occasionally Operational Data Stores (ODS). You can click on the links to learn more about each of those tools/approaches, but the basic idea is to leave the data where it is, in the format that makes sense for the team in charge of it, but provides access and views that make the data usable.

Leave the data where it is, in the format that makes sense for the team in charge of it, but provides access and views that make the data usable.

Microservices with versioned API’s, backed by legacy databases, implemented via request/response or pub/sub application communication models, are the easiest application EVAR. It’s simple to spin them up and scale them using containers and OpenShift.  Using this approach, you can provide multiple data views of the data, and add more as new connections and ways of thinking appear.

If you need to do your own analytics or heavy-duty data processing/lifting, you can use a temporary or semi-permanent (but not the source of truthdata store such as an in-memory database or an ODS. Again, these are faster to set up and and more importantly faster to change than a legacy system of record, and they provide a nice balance between the speed of APIs and the performance of an enterprise database.

Conclusion: MDMs Generally Suck (Relative to Alternatives)

I would love to be wrong. I’d love to hear some new innovation that makes MDM make sense. But I’ve seen too many MDM initiatives rust out and die, and I’ve seen way too many API projects succeed wildly.

Don’t MDM, API.

OpenShift 4 Migration: A sample path

OpenShift 4 Migration: A sample path

The Problem

Moving stuff between Kubernetes clusters can be a pain in the butt. You have to do this when:

  • Migrating between container platforms, such as EKS -> AKS
  • Upgrading clusters when you want to upgrade in parallel (move everything from old to new) as opposed to upgrading in-place (update one cluster from old to new). This would be something like what we’ll talk about in a minute, going from OpenShift 3.x to OpenShift 4.x
  • Moving work/applications between clusters, e.g. two clusters in different datacenters

Migrating work between clusters requires some thought and planning, and good solid processes. Specifically, the migration from OpenShift 3.x to OpenShift 4.x requires a parallel upgrade, because there is no in-place upgrade available for all of the new goodies in RHEL CoreOS (the underlying infrastructure of the cluster). OpenShift 4.2 released recently, so we thought it would be good timing to put our migration thoughts down here. However, the advice below is generally good for any Kubernetes cluster parallel upgrade or other migration.

Read More Read More

Why Developers Love SonarQube

Why Developers Love SonarQube

We’ve seen a lot of tool transitions across a large enterprise, and one of the coolest examples was changing the opinion of the company we worked for regarding source code analysis. We had a tool that was under-licensed, slow, ineffective, and largely ignored. At best, it was a check box labeled “we’re definitely secure, you guys!” that everyone on the ground ignored.

Read More Read More