Embrace the Ick

I have several friends who are U.S. Marines. Frequently in conversation with them, I've heard them refer to "the Suck". The Suck, as they call it, is a label for anything undesirable or unpleasant, something they have to do but don't necessarily want to do. It goes something like this:

"Yeah, I broke my collarbone in a motorcycle accident and I haven't been to the gym in 3 months. Gotta embrace the Suck before I lose this 6-pack."

or

"I just got deployment orders, I'm leaving next Thursday. Heading back to the Suck."

While a software engineer isn't likely to face anything with quite as much "Suck" as deploying to a combat zone, I think we do have a similar reaction to certain tasks... one of them being Compliance work. I'd like to call this "the Ick".

The Developer who enjoys working on Compliance or Audit Evidence-gathering is a pretty rare unicorn... Most of us treat it as a distraction from work rather than understanding that in a regulated environment, it IS the work.

What's more, the Ick is invasive: If you don't control the "Ick", the "Ick" will control you.

How We Got the Ick

Long ago, when the company was either smaller or less-regulated (or maybe both), audits were rare enough that they didn't disrupt the development teams' work. But somewhere along the way, the time between audits narrowed (and/or the complexity of the requirements increased) and we started to feel the effects. Management didn't like the lost productivity of the dev teams, and they took it upon themselves to solve the problem... by carving out organizational space to deal with audits.

Once an "audit team" existed, developers interpreted compliance work as "less-desirable", or "not worth their time". Gradually they were conditioned to ignore -- and then to avoid -- the audit requests. "Let the Compliance Team figure that out, I'm not getting involved."

The Ick began.

But they were all of them deceived...

Every time a developer thought like that, every time they neglected the audit requests... they abdicated control of their environment to someone who, as we talked about last week, had clean hands.

And those folks, well-meaning but uninformed, did the best they could to make audit decisions without the experience of being a software engineer. Their desire is to achieve security through control... set up enough rules and restrictions, lock all the doors, and...

If something escapes control? Fight back the one way we know how: paperwork. Build a process, schedule a meeting, add another line to the spreadsheet... lock down the change so that it can be subdued.

By the time the developers realized what had happened, they were bound by Security Theater: draconian rules and policies that did little to keep the organization secure while making it harder to keep the organization successful. And when anything unexpected occurs, the noose tightens just a little more, until we've strangled the organization completely in the name of keeping it safe.

Vulcan Proverbs

This problem can only be solved if developers get directly, deeply involved in the audit compliance process again. No one else in the organization has firsthand knowledge of how the organization actually delivers its work. But they've been conditioned for years now to think of compliance work as "undesirable". We have to change the mindset... to "Embrace the Ick", if you will... so that when the new regulation rolls out, it can be addressed in a way that satisfies all of us.

Embracing the Ick: Some Practical Steps

How can Developers "embrace the Ick"? What specifically can we do? Let's look at a few ideas:

Learn the Language of Compliance

This is table-stakes. Compliance Controls are just words, y'all. They might seem intimidating as they have all these fancy "family names" like CM-3 and RA-5 and other things that sound like Star Wars Droid Characters... but if you crack those open, inside you'll just find WORDS. Read them. Understand what they're asking for. Ask your favorite AI to summarize them like you're 5. But you should be fully acquainted with the contents of all the controls you're bound to follow in your organization.

...That means getting someone in Compliance to tell you which controls are in your standards. Go track them down and ask them. If they survive the heart attack of a developer wanting to know more about their world, I'm sure they can put together a comprehensive list (probably in a spreadsheet 🙄) for you to keep as a reference.

Take your time to digest

Yes, I know your goal is to replace those annoying compliance officers with very small shell scripts. I'm not even saying that's a bad goal to have. But you're going to address a system that has spent years evolving into the beast that's consumed so many good dev cycles.

You should be methodical about your process here:

• Read and understand the goal of the control.
• Imagine automatic ways to achieve it.
• THEN imagine ways that your automation can be poked full of holes.

Assume the ride will be rough

You'll need to expect resistance to your automation suggestions... just as you've spent a long time developing mistrust for auditors who don't know an npm install from a helm chart, you're communicating with people who have spent years dealing with developers who treated them like 💩 instead of explaining themselves in ways that the layman could understand.

It's almost like... a little empathy would be valuable. Crazy, huh?

The Developer's Mental Shift

The real hurdle for the Developer is realizing that Audit Evidence is just automated testing for adults. Just like you "prove to a linter that your code won't break the build", you can "prove to an auditor that your deployment won't break the company". When you "Embrace the Ick," you stop providing "screenshots of a ticket" and start actually providing real evidence. You just need to show them how your real evidence is an improvement over the screenshot!

Take Your Trip to China

Once you speak the language and have the empathy, you can do what no one else can: Negotiate.

Instead of the Ick's manual "Change Approval Board"?
Offer a signed GitHub Action that enforces peer review.

Instead of the "quarterly manual access review"?
Offer an automated daily report from your Identity Provider.

You don't "go to China" to surrender; you go to sign a treaty that replaces their manual shackles with your automated gates. And when they're automated, I guarantee that you'll exceed their manual process's resolution.

You have a manual API key rotation rule of 90 days? Our script can rotate them weekly. Or even daily. --See what I mean? 😏

Conclusion

We’ve spent a decade trying to "shift left" on security and testing... but now it’s time we shift left on Sovereignty. If we continue to treat the regulatory requirements of our industry as "someone else’s problem," we are consenting to live in a world built by people who don't understand our craft. We are effectively choosing to be governed by the least informed people in the room.

The "Ick" isn't going away. The regulations aren't getting simpler. But the "Sovereign Engineer" knows that the only way to maintain the speed and freedom we love is to own the boring stuff ourselves, while ensuring that we bring our compliance folks along with us as we automate it.

Don't just survive it... OWN the Ick. Build the system so well that the audit becomes the easiest part of your week.

After all, if you don't define the controls, the controls will define you.