When the decision to do Scrum is made several levels above the programmer, and retrospective meetings (if they happen at all) never address problems with Scrum itself, and Jira (with its required fields and workflows) cannot be modified by developers, and management won’t engage with our complaints, we are pretty much stuck.

If companies continue to operate like this, we’re going to have to get more creative.

Here are a few of my latest thoughts on the issue:

1. Start Your Own Business or Do Freelance Work

This is the path I am most focused on lately, and I hope to provide some useful references soon. I'm chronicling my journey on this road as it unfolds and hope it will be encouraging for others to read about. Wish me luck! The idea here is to exit the system altogether. If working for others is going to be this painful, then starting a company can’t be any worse. Right?

2. Shadow Projects

Shadow projects are when you do your own thing, but you are still at work. It’s stuff that will help the company that isn’t necessarily “prioritized” or “sanctioned.” You work on it (secretly) alongside your normal work.

The key shift here is asking forgiveness instead of permission. Because backlogs take all the control away from individual engineers, secretly working on things that you feel are important and/or interesting is a way to take some control back.

3. Civil Disobedience

One place I worked, I stopped attending my daily stand-ups—in protest. The Scrum Master wouldn't allow the team any control or even time to coordinate our day. As soon as members were finished reporting their status (yesterday-today-no-blockers style), he would abruptly end the meeting. By skipping it, I never missed a thing. More than that, the tone of the meeting was confrontational and anxiety-inducing. I told HR the meetings were causing me mental distress.

Eventually, HR determined that Scrum was an "industry standard," so I had no recourse. My boss gave me a written warning that if I did not return to stand-ups, I would be terminated.

Eventually I caved and returned to my stand-up meetings (and started interviewing for a different job), but this action demonstrated a glimmer of potential. I could tell my manager was quite distressed to start down the path of firing me (I was the team lead, had positive annual reviews, was liked by many high-ranking engineers, and had recently received an award for teamwork). Had I not been the only one actively resisting Scrum (everyone hated it but few took step to fight it), or HR had more actively investigated my situation, I may have gotten more traction.

In retrospect, I wish I had held firm to at least see what would happen—I think I had more leverage than I realized. Regardless, I learned an important lesson. Civil disobedience has potential. If deployed effectively, it could be a powerful tool.

4. Malicious Compliance

When work requirements are clearly ridiculous, one option is to simply comply. Do everything they tell you to—even though you know it will torpedo the project. Don’t go above and beyond to rescue it; let the system play out as instructed. Just let the ship go down. In the wake of catastrophe, if you can clearly demonstrate there was zero negligence on your part, then (maybe) the system will take the blame.

This isn’t sabotage. It’s obedience—letting the system reveal its own flaws without rescuing it.

But beware. When a project fails, accusations will fly. For the most part, developers are not present in the right meetings to rebut or even be aware of many of the arguments hurled against them. So, your case has to be air-tight and self-evident—perhaps even presented in writing to provide a presence even in closed-door meetings where developers are not permitted.

5. Unions

I haven't looked too deeply into this option, but it's the classical way for workers to gain workplace representation. It has worked in other industries, so I think it has potential in ours. While I am most inclined to put my energy into starting my own company, I wholeheartedly support anyone else’s effort on this front—and would love to re-stack other people's research on the topic.

6. Spread Awareness

Keep talking and writing about the realities of forced Scrum. Share stories, document the harms, and expose the contradictions. It may take time, but as more people speak up and the costs of the system become undeniable, change will follow. History shows that flawed systems eventually crumble—but only if the truth is continually on display.

Close your eyes.
Take a slow, deep breath.
Let your shoulders drop.

Picture the people who report to you — your team.
Not as a list of names, but as human beings.
See each face. Remember each voice.

Now, think about the mandate they’ve been given.
The problems they are here to solve —
for the customer,
for the organization,
for the world.

Hold these two things in your mind:
your team, and their purpose.

Notice all the other things swirling around them:
Schedules. Meetings.
Process frameworks. Management dashboards.
Stakeholders offering advice — or demands.
Policies. Plans. Projections.

Some may be useful.
Others may not.

Let’s return to first principles.
Let’s strip it all away.

One by one, imagine removing these external items from your team:

Wipe away each process — Scrum, Agile, sprints, estimates, forecasts.
Wipe away each policy.
Wipe away culture and tradition.

Keep going until there is nothing left —
no charts, no frameworks, no rituals.
Just people, and a goal.

Sit in this emptiness.
Now, return to each person on your team.

What energizes them?
What are they uniquely capable of?
What do they need from you to succeed?
What do they want for their own career —
and how can that connect to the team’s purpose?

Notice where their personal goals align with the work.
Notice where they don’t — and what you could do to bridge that gap.

Only now may you begin to add things back.
Choose the processes that supports them in reaching their goals.
Choose policies that protect their time and focus.
Choose tools that amplify their strengths.

Do not slap a pre‑made process over the top of your team —
as if it were one‑size‑fits‑all.
Design the process around the people.
Tailor it to each unique individual.
Around their skills.
Around their needs.
Around their growth.

This is what it means to be a manager.

Open your eyes.
Jot down what came to mind.
Set yourself to achieving it.

And every so often, return to this place —
strip away the noise,
and remember what is essential:

People.
Purpose.
And the space you create for them to succeed.

Of the four tenets of the Agile Manifesto1, one gets the least attention:

"Working software over comprehensive documentation."

I used to wonder if this line was still necessary. Waterfall is dead, right? We don’t write 40-page specs anymore. We iterate. We deploy constantly. Who even reads documentation? But then along came ADRs — and suddenly, waterfall was back.

While documentation isn't forbidden by the Agile Manifesto, it should always take a backseat to the most important document: the source code. You’ll hear people claim that ADRs, RFCs, and other formats are a modern, Agile-friendly kind of documentation — sleeker, lighter, more collaborative than the bloated specs of the '80s and '90s. But in practice, they break the single most important rule of useful documentation:

Documentation should describe the current state of software, not future aspirations.

It’s that simple.

Documentation that reflects intention, aspiration, or “alignment” might feel useful — but it turns stale the moment real feedback hits. Plans change. Code evolves. No plan survives contact with the enemy.

That’s why documentation should follow implementation: to stay grounded in reality, not stuck in a pitch deck. When written too early, docs have a way of becoming gates — demanding buy-in, slowing progress, inviting bureaucracy.

Agile isn’t about asking permission. It’s about moving fast, learning as you go, and letting the code lead.

Documentation That Fails

There’s a new class of documentation making the rounds in modern software teams. It looks clean. It lives in Git. It uses Markdown and has PRs and approvals. It feels agile-ish — but functionally, it’s just hipster waterfall.

Some common offenders:

• ADRs – Architectural Decision Records are documents used to capture important technical decisions about a system — typically outlining the context, options considered, the chosen approach, and reasoning behind it.

• RFCs – Requests for Comments are documents shared within an organization to propose a change, invite discussion, and gather feedback from stakeholders before implementation begins.

• Alignment Docs – Alignment documents are often used when multiple teams are collaborating and want to clarify shared goals, responsibilities, timelines, or interfaces to avoid conflicts and miscommunication.

These docs are clean. Structured. Reviewed. And deeply fictional.

Agile is iterative. You try, you check, you try again. But these types of documents — especially when written beforehand — don’t reflect that reality. They freeze assumptions before they’ve been tested and codify them as barriers to change.

Worst of all, these documents quickly morph from collaborative artifacts to bureaucratic hurdles. Once written, they attract approvers. Suddenly, progress hinges on buy-in. What starts as a discussion becomes a checkpoint — a justification — a gate. And who benefits from that? Usually not the engineers. These docs tend to serve management’s need for perceived control more than a developer’s need for real clarity.

Coding Is More Like Painting

When painting, you draw a few lines. Step back. Add a little color. Erase something that felt wrong. You start to get a sense of what the painting wants to become. That’s the process.

Writing an ADR is like composing a detailed essay about your sketch — before you’ve decided whether to keep it, paint over it, or throw the whole canvas out. Even worse, once the essay exists, you’re obligated to justify why your final painting doesn’t match the thing you wrote when the canvas was still blank.

That’s why ADRs and RFCs so often become problematic. They:

• preserve assumptions that no longer make sense.

• make it harder to change direction without "justifying the deviation."

• create process drag instead of technical alignment.

• encourage teams to commit too early to ideas that haven’t been pressure-tested.

In fact, if your ADRs aren’t out of date, that’s a red flag.

If your ADR is accurate after three sprints, you’re ignoring what the code is trying to tell you.

Good teams learn. They adapt. They refactor. And when they do, the documentation rots. If it doesn’t, you’re not learning. You’re not Agile.

Documentation That Succeeds

Documentation that works doesn’t try to predict the system. It describes it. Faithfully. Honestly. And in sync with reality.

That means no aspirational roadmaps disguised as design docs. No idealized blueprints frozen in time. Just living documents that reflect what the code actually does — as it changes.

Here’s what tends to work:

• Generated docs — These are the gold standard for staying accurate. Because they’re built directly from the codebase, they evolve when the code evolves. API documentation, database schemas, typed interfaces, route maps — if you can generate it, you should. These docs can’t drift because they’re pulled from the source of truth.

• Inline code comments — When kept up to date, these are small but powerful acts of code annotation. They sit where the context lives, next to the logic they describe. They’re small, conversational, and close enough to get deleted or updated the moment they lie.

• Project READMEs — A well-written README anchors a project. It describes what the code does right now, how to run it, and how to contribute. When maintained alongside the codebase, it becomes the most accessible, low-friction entry point to understanding a system. It's not aspirational — it's operational.

• Literate programming — This is where narrative and implementation meet. Code and commentary live together, woven into the same artifact. When you explain what your code does in the same place that it does it, you force clarity of thought and invite better structure. Literate programming doesn’t tell stories about what might exist; it tells the story of what exists now.

All four approaches work because they are anchored to the code itself. They resist drift. They avoid fiction. And most importantly:

They document the system that exists — not the one someone hoped would exist when they wrote a Google Doc three weeks ago.

Can’t Serve Two Masters

Is it any wonder the authors of the Agile Manifesto valued working software over comprehensive documentation? They’ve seen what happens when teams make documentation the source of truth: endless effort poured into updating, reviewing, versioning, syncing — and still, it lags behind reality. They've seen documents become bottlenecks waiting for approvals.

You either prioritize working software or comprehensive documentation. The Agile Manifesto chooses working software. Or as Facebook’s old hacker culture doc put it:

“Code wins arguments2”

You can spend your day updating documentation and chasing signatures — or you can make real progress in your code. Which would you prefer?

Literate programming (LP) is good for a lot of things: it keeps your code and documentation in sync, lets you present code in the most logical order, and helps remove stubborn duplication. But most people are unfamiliar with how it works for testing.

And for testing, LP soars—it may very well be LP’s killer feature. You can mock, fake, and stub easily—all without a framework. It works just as well for C/C++ or other compiled languages as for scripting languages. It gives you a clear way to declare which dependencies you're faking and which you're not. And it turns testing into a joy by wiping away boilerplate and letting you think directly in your target language. Integration tests become as easy as unit tests.

Once you try it, you’ll never want to go back.

Mock a C function

Let me whet your appetite with an example. We’ll build a simple program in C—a language notoriously difficult to mock without resorting to linker tricks (like `-Wl,--wrap=<func>`) or other ugly maneuvers. Not so with LP. Check it out.

Here’s a function that prints the current date repeatedly. It takes one argument: how many times to print the date.

Below is a literate file1 called `main.o.md`2.

# Application Code

## main

```C {tangle=main.c}
#include <stdio.h>
#include <time.h>

@<print_date_repeatedly_def@>

int main()
{
    print_date_repeatedly(10);
}
```

## print_date_repeatedly

```C {name=print_date_repeatedly_def}
void print_date_repeatedly(int count) 
{
    for (int i = 0; i < count; i++) 
    {
        time_t now = time(NULL);
        struct tm *local = localtime(&now);
        printf("%s", asctime(local));
    }
}
```

## Build and Run App

```bash {name=app}
gcc main.c -o app
./app
```

To run, type the following in terminal in the same directory as this file:

omd tangle && omd run app

You should see the following (with a different date/time though):

Sat Jun 14 13:38:40 2025
Sat Jun 14 13:38:40 2025
Sat Jun 14 13:38:40 2025
Sat Jun 14 13:38:40 2025
Sat Jun 14 13:38:40 2025
Sat Jun 14 13:38:40 2025
Sat Jun 14 13:38:40 2025
Sat Jun 14 13:38:40 2025
Sat Jun 14 13:38:40 2025
Sat Jun 14 13:38:40 2025

Pretty easy. But now let’s try to test it.

That’s not so easy.

Let’s simplify and say we trust the date/time code, but we still want to test that the output is printed the correct number of times. That should be easy, right? Nope.

Ideally, we’d just call `print_date_repeatedly()` with different values for count and check that it prints the expected number of lines. But there’s a problem: the output goes to `stdout`, so you have to capture it somehow and count the lines.

Here’s how you can test it using LP. Just add this section to your `.o.md` file:

# Testing Code

```C {tangle=print_date_repeatedly.c}
#include <stdlib.h>
#include <time.h>

int times_called = 0;
int printf( const char* restrict format, ... )
{
    times_called++;
}

@<print_date_repeatedly_def@>

void test_calls(int count)
{
    times_called = 0;
    print_date_repeatedly(count);
    
    // was I called the right number of times?
    if(times_called != count)
    {
        exit(-1);
    }
}

int main()
{
    test_calls(0);
    test_calls(1);
    test_calls(2);
    test_calls(3);
    test_calls(10);
    test_calls(100);
    
    // everything passed
    exit(0);
}
```


```bash {name=test}
gcc print_date_repeatedly.c -o app_test
if ./app_test; then
    echo "Success!"
else
    echo "Failure! Exit code: $?"
fi
```

This creates a separate test binary that returns `-1` on failure and `0` on success. To run the test:

omd tangle && omd run test

You should see:

Success!

Notice how we use the `@<print_date_repeatedly@>` reference to include the same code in both the application and the test. Referencing code this way acts like an automated cut-and-paste—but better. Instead of importing everything (with all its dependencies), you bring in just the code you want.

In this test, for example, we omit `#include <stdio.h>` so we can safely mock `printf`. And we could do the same thing for any function called by `print_date_repeatedly`—system call or not.

And the really remarkable thing? We don’t need a library or framework to mock it.

And this is C! Try doing that without LP.

A Clean Split

With LP, you can place the test code right next to the function it’s testing. No need to hunt through some distant `tests/` directory. In fact, I recommend splitting the code above into two files: one for `main`, and one for the function (with its tests):

main.o.md

# main

```C {tangle=main.c}
#include <stdio.h>
#include <time.h>

@<print_date_repeatedly_def@>

int main()
{
    print_date_repeatedly(10);
}
```

# Build and Run App

```bash {name=app}
gcc main.c -o app
./app
```

print_date_repeatedly.o.md

# print_date_repeatedly

```C {name=print_date_repeatedly_def}
void print_date_repeatedly(int count) 
{
    for (int i = 0; i < count; i++) 
    {
        time_t now = time(NULL);
        struct tm *local = localtime(&now);
        printf("%s", asctime(local));
    }
}
```

# Testing Code

```C {tangle=print_date_repeatedly.c}
#include <stdlib.h>
#include <time.h>

int times_called = 0;
int printf( const char* restrict format, ... )
{
    times_called++;
}

@<print_date_repeatedly_def@>

void test_calls(int count)
{
    times_called = 0;
    print_date_repeatedly(count);
    
    // was I called the right number of times?
    if(times_called != count)
    {
        exit(-1);
    }
}

int main()
{
    test_calls(0);
    test_calls(1);
    test_calls(2);
    test_calls(3);
    test_calls(10);
    test_calls(100);
    
    // everything passed
    exit(0);
}
```

## Run Tests

```bash {name=test}
gcc print_date_repeatedly.c -o app_test
if ./app_test; then
    echo "Success!"
else
    echo "Failure! Exit code: $?"
fi
```

With time, you can add more functions in their own files—each with its own tests—and manage them in a clean, modular way. Everything stays isolated and easy to understand. Add some docs and links between files, and you’ll have a first class literate program!

Conclusion

Literate programming isn’t just a clever way to organize files—it’s a fundamentally different way of thinking. Your code and your thinking grow side by side. Your tests live where they belong: next to the ideas they verify. You stop writing tests as an obligation, and start writing them because they’re part of the story.

For years, I've been searching for ways developers can shield themselves from misguided productivity management. I've tried everything, but management persists. Arbitrary targets and proxy metrics seem endless.

The idea respawns somewhere new as soon as it gets its head chopped off. Just look at how often someone tries to start a new company based entirely on the claim that they've figured out how to reduce programming effort and efficiency to a handful of numbers. ("No! I swear! This time it's for real.")

Most days, it feels like programmers are doomed to live under the outdated ideas of scientific management.

But today, I had an idea—something that's been right there in front of us all along: Pair Programming.

The Hidden Power of Pair Programming

Besides the benefits its proponents tout—faster onboarding, better sharing of institutional knowledge, more natural code reviews, increased team energy—pair programming could be the key to freeing developers from relentless individual scrutiny.

Here's the idea: if developers collectively insisted on pair programming—making it an absolute requirement rather than an occasional practice—they could effectively shield themselves from individual metric tracking.

Because there would be no such thing as individual programming effort.

Bam!

Restructuring Task Management Systems

To achieve this, existing software tracking systems would need adjustments. Most importantly, no developer would ever pull individual tickets from task management systems like Jira, Pivotal Tracker, or Asana. Instead, tickets should always be claimed by pairs or groups. While these tools don't inherently support team-based ticket assignment, creative solutions exist. Teams could adopt shared names or aliases for pairs, ensuring no task is tracked back to a single individual.

This seemingly minor shift is revolutionary. By removing individual accountability from tracking systems, management loses the ability to target developers individually based on arbitrary metrics. The burden is lifted.

Strength in Numbers

The benefits don't end there. When developers work in pairs or small groups, they can more effectively challenge unrealistic expectations or poorly conceived requirements. It's far harder to dismiss the collective voice of two or more developers pointing out problems than to label an individual as lazy or incompetent. Additionally, pair assignments diffuse blame and prevent unjust targeting of any single developer for setbacks or delays.

This realization excites me, although I know it's not entirely new. (I'm sure that if Kent Beck is reading this, he’s saying, "Well, duh!")

Pair Programming as Civil Disobedience

Pair programming can be more than just an effective development practice; it's a subtle yet powerful act of civil disobedience. By insisting on pairing, developers reclaim autonomy and push back against micromanagement without significant confrontation. They merely have to advocate for the already well-established benefits of pairing and insist on using it.

Developers should unite under this simple principle: "I only pair." Make the banners, print the flyers, knock on doors, and gather signatures. It's time to restore sanity, productivity, and enjoyment to programming.

Individuality Still Thrives

By no means does pair programming erase individuality. Like participating in a college study group, pairing augments individual capacity through sharing and collaboration. Developers still have ample opportunities to independently research new ideas, prototype solutions, and deepen their expertise outside tracked tasks. This balance allows developers to express unique strengths and autonomy while collectively resisting harmful management practices.

Individual talents will still shine—just in more collaborative moments, which gives more satisfaction anyway. Pairing doesn't hide anyone's skills; it merely enforces what Tom DeMarco and Timothy Lister suggested in their influential book Peopleware:

Work measurement can be a useful tool for method improvement, motivation, and enhanced job satisfaction, but it is almost never used for these purposes. Measurement schemes tend to become threatening and burdensome.

In order to make the concept deliver on its potential, management has to be perceptive and secure enough to cut itself out of the loop. That means the data on individuals is not passed up to management, and everybody in the organization knows it. Data collected on the individual’s performance has to be used only to benefit that individual. The measurement scheme is an exercise in self-assessment, and only the sanitized averages are made available to the boss.

…The individuals are inclined to do exactly the same things with the data that the manager would do… The manager doesn’t really need the individual data in order to benefit from it.1

Programmer’s can still measure anything the would like about their own performance. They are simply cutting management “out of the loop”.

Addressing the Parallelism Myth

Of course, some will argue that pair programming removes the benefits of parallelism: two people could otherwise be working on two separate tasks, theoretically doubling output. But this doesn't hold in practice. Firstly, two programmers working on the same task usually complete it faster and with fewer errors than an single developer. Secondly, pair programming removes one of software development’s greatest productivity killers: code reviews.

In traditional workflows, code languishes for hours or days awaiting review and approval. With pair programming, peer reviews become intrinsic to the development process. As soon as a task is completed, it has already been sufficiently reviewed and can be immediately merged into the main code branch. In most cases, this speedup alone outweighs any supposed benefits of parallelism.

Conclusion

The path forward is clear: remove individual names from task tracking systems, insist on pairing, and reclaim our profession. Together, we can resist misguided productivity metrics and restore joy, sanity, and true productivity to software development.

If your SOC 2 compliance requirements seem excessive, you only have yourself to blame.

That’s the dirty little secret of SOC 2 compliance that management hasn’t been so eager to explain. Most developers imagine there are evil compliance officers breathing down the company’s neck, forcing it to lock everything down. They assume that long ticket queues, deployment request forms, and code review requirements are all part of some SOC 2 rulebook.

If you’ve ever complained, you’ve probably gotten the standard reply: "We can't do anything — it’s a SOC 2 compliance issue."

But the truth is, there is no SOC 2 rulebook. There are no external compliance officers. SOC 2 isn’t a list of mandatory tasks like a regulation. It’s a framework where you write your own rules and prove you follow them. Of course, they need to be reasonable enough to pass audit scrutiny. But the organization chooses the rules — not some outside body.

So if controls are overly rigid and painful, it’s because the company chose to make them that way. They’re the ones tasked with creating the controls.

The pain is self-inflicted.

Who Really Makes the Rules?

At big companies, there may be dedicated security and compliance professionals. They might even call themselves compliance officers, but don’t be confused — they work for your company, not a regulatory body.

In smaller organizations without dedicated compliance professionals, the task of choosing and maintaining SOC 2 compliance rules normally falls to the Ops, DevOps, or Platform engineering teams.

Regardless of who inside the company is setting the rules, one thing is certain: the company itself is in charge, not the SOC 2 auditors.

And you don’t have to take my word for it.

While some security frameworks like ISO 27001 and PCI DSS have rigid requirements, that isn’t the case with SOC 2.

Controls and attestation reports are unique to every organization.

Each company designs its own controls to comply with its Trust Services Criteria.

An independent auditor is then brought in to verify whether the company’s controls satisfy SOC 2 requirements.

After the audit, the auditor writes a report about how well the company’s systems and processes comply with SOC 2.1

… organizations are given full autonomy over which TSC they develop controls for as well as what those controls consist of.2

Another thing is certain, developers aren’t being consulted when compliance controls are designed—even though compliance controls directly effect their daily workflows.

This needs to change.

Principles for Developer-Friendly Compliance

How do we escape this bureaucratic mess and build developer-friendly compliance?

The way out is to design systems around better principles. Here are five that can help recalibrate an otherwise overly restrictive set of compliance practices.

Principle 1: Better Defaults

Some operations teams default to zero access, forcing developers to request every single permission individually — a tedious, frustrating, and unnecessary mode of operation.

All developers on a team typically need the same permissions. It’s much more efficient to grant those permissions as a block, upfront, for every member of the team. They’re going to be approved eventually, so you might as well save yourself from fielding a dozen tickets just to get someone onboarded.

Better defaults also empower discovery. Developers can see what’s available, experiment, and move faster without waiting in line for approvals.

Another smart default is granting better access to CI/CD systems. Without proper access, it’s nearly impossible for developers to build, debug, and tune their pipelines.

Principle 2: Sandboxed / Prototyping Environments

Developers need environments where they can safely explore, experiment, and learn — with real access to cloud services, infrastructure definitions, and deployment tooling.

Give developers direct access to Terraform files, Kubernetes manifests, and CloudFormation templates. Let them prototype infrastructure changes in dev environments without gatekeeping. Not every change must be fully polished in every iteration and prototypes are part of the learning process.

Formal reviews can wait for when changes move to production — after developers have had the chance to spin up resources and see how they work. Later, when they’ve formalized their work into a pull request, ops engineers can review the cloud configurations they create.

Developers who have full control in dev environments write better, safer production systems — and you avoid turning every infrastructure change into a ticket queue nightmare.

Principle 3: Avoid Unnecessary Abstractions

Every time you wrap an API in a bespoke internal tool, you add latency and risk.

Internal wrappers over cloud APIs might seem helpful — adding guardrails, simplifying complexity — but too often they just create hard dependencies on the operations team. Developers get locked out of directly configuring infrastructure. And when cloud providers release new features, you lag months behind because your wrapper hasn’t caught up.

Good abstractions empower developers. Bad abstractions create dependency loops. The best approach is to give developers direct access to manifests and configuration, with clear policy guidance, rather than hiding everything behind custom tooling. Native manifests and configurations are already auditable. That’s as far as you need to go.

Unnecessary abstraction is unnecessary complexity.

Principle 4: Favor Visibility Over Restriction

Restricting access might feel safer, but it often does the opposite.

Visibility is a better security posture. Open systems let developers understand how things work, spot problems early, and contribute to improvements. It’s the same principle that makes open source software often more secure than closed systems: more eyes, fewer surprises.

Defaulting to locked-down, opaque systems hides risks and slows down diagnosis when things go wrong. Instead of "security through obscurity," aim for transparent systems with auditable logs and clear visibility into operations.

Allowing all code repos to be at least readable by anyone in the organization, for example, makes it hard for nefarious code to see the light of day. It also makes it easy for all developers to check and contribute to each other—a requirement for any high functioning software organization.

Principle 5: Interim Controls

The road to automation is long. But that doesn’t mean you have to live in ticket hell while you're trying to get there.

Most ops teams agree: the best solutions use self-service and automation. This is typically their long-term goal. But ops teams often get so overwhelmed with their near-term manual processes that they never get around to their automated end goals. Manual access approvals, manual deploy reviews, manual evidence collection — they devour the time and energy that could have gone toward building a better solution.

Be careful to design interim controls that are not only sufficient from a compliance viewpoint, but that also don't take up all your time.

For example: use templated requests that reduce manual decision-making. Grant permissions in blocks (see Principle 1). Let devs manage their own CI/CD pipelines. Do whatever you have to to avoid getting buried under a mountain of Jira tickets.

Trust that auditors will accept these interim solutions in light of your long-term goals.

Don’t accept the false choice between painful manual processes today and full automation someday (a day that may never comes). There’s a temporary middle road that can get you to your goal faster.

Yes, You Can Change SOC Controls (And You Should)

Here’s another dirty little secret: SOC 2 controls are not set in stone. Despite what they may say at your company, you can absolutely change them. In fact, mature companies revise their controls all the time as they automate processes, improve risk posture, or grow out of old startup-era hacks.

If management says, "We can't fix that because of SOC 2," when confronted with a poorly designed control, you can (and should) reply: "Then it’s time to fix it."

If you switch from manual approvals to automated pipeline enforcement, you haven’t weakened your posture — you’ve improved it. Good auditors know and accept this. They care about outcomes, not ceremony. There is nothing sacred about your first attempt at defining controls. What matters is getting it right eventually.

If you’ve inherited bad controls? Change them!

If a policy is crushing your developers? Replace it!

Your controls are yours to define.

If you don’t take charge of improving your controls, you’ll be stuck living with someone else’s bad decisions forever.

Developer Action

If you’re a developer, and you’ve felt powerless to push back against excessive bureaucracy, hopefully this essay has made you feel more empowered.

You should feel comfortable challenging a painful status quo. Push back against:

• Controls that are more performative than useful.

• Ticket queues and approval bottlenecks.

• Manual processes.

• The lack of sandboxed environments.

• Wrappers around available cloud tools.

• Opaque systems.

Treat compliance design as an engineering responsibility. Good compliance should feel like good engineering: reliable and low-friction.

Your company wrote the rules.

Now make them write better ones.

Disclaimer:
This post reflects my personal opinions and experiences and is not legal or compliance advice. Always consult with your own legal counsel and auditors when making decisions about your compliance strategy.

We need to talk about DevOps.

In the beginning, DevOps made sense. It was a logical evolution of healthy engineering practices. But we never should have given it a name. Once we labeled it, it got completely out of hand.

Before DevOps, developers would write software and hand it off to an operations team, who then had to figure out how to get it running in production. This didn’t work very well. Eventually, developers who cared about deployment started getting involved in making sure their code made a smooth transition to production. That was a huge improvement.

And that’s where we should have stopped.

We should have just said: “Hey, developers should deploy their own code.” More than that—they should also be responsible for keeping it running. They should monitor it, respond to issues, and use their programming skills to automate deployments so they’re safe, repeatable, and easy for the team to use. Production-minded developers (who are part of the team!) should do a little extra work to make things better for everyone. This was the correct mindset—a necessary shift away from isolated ops teams managing production without developer participation.

When cloud services arrived, this shift became even more natural. Spinning up a server was no different than calling an API. Infrastructure could be programmed. It could be versioned. It could be tested.

But then we made a terrible mistake: we gave it a name—DevOps.

Suddenly, developers who were good at working with production systems were given a new title. And as soon as “DevOps engineer” became a role, people started forming DevOps teams. That was the beginning of the end.

When we created DevOps engineering teams, we pulled engineers away from product teams and gave them a new mission. We left product development teams without anyone focused on production. We undid everything that made DevOps work in the first place.

Effectively, we created a new operations team called DevOps, and operations went back to managing production in isolation. Sure, they adopted newer tools and sprinkled in some automation. But that’s really beside the point, because the real benefit of DevOps came from empowering developers to own their deployment pipelines and automate their production processes—tailored to their team’s specific needs.

Once again, companies tried to standardize everything and chase economies of scale. In the process, they stripped DevOps of its usefulness.

Now, DevOps teams build internal tooling designed more to restrict than to empower. They wrap every API in layers of homegrown abstractions, which fall behind what cloud providers like AWS already offer. Developers end up begging for support for features that are already standard elsewhere.

Originally, DevOps was about trusting developers with production. But modern DevOps teams operate on the belief that developers can’t be trusted with production. And because DevOps owns the compliance checklists, they bake that mistrust into the rules. SOC compliance, for example, ends up filled with restrictions that assume developers are potential bad actors—rules that hinder more than they help.

Of course, this is all completely pointless. A DevOps engineer is just as capable of malicious behavior as any other engineer. The solution isn’t to block access—it’s to make actions transparent and reviewable. Security comes from visibility, not locked doors.

So what did creating a “DevOps” role actually get us?

It pulled production-minded engineers off their teams and stripped those teams of both the interest and the permission to manage their own production environments. We ruined the idea of DevOps by formalizing it.

P.S. Platform Engineering is the same story. In the words of Yogi Berra, “It's déjà vu all over again.”

I just re-read Do Androids Dream of Electric Sheep by Philip K. Dick (PKD). It's a good one—and it hit me differently this time. Beyond its insights into dilemmas we may soon face with AI, it also says a lot about the plight of today’s laborers.

Rick Deckard's job is to hunt and retire (i.e. kill) androids—because he's a bounty hunter, and androids are forbidden on Earth. Occasionally, a few make their way back from off-world colonies and hide out, pretending to be human, so they have to be exterminated.

Over time, the androids become nearly indistinguishable from humans, and that starts to mess with Deckard. He begins to feel guilty about killing them. He develops too much empathy.

Yet he still feels pressure to do his job—and he still needs the money. So he's torn. At one point, he decides he's done with it:

"This is my end," he said to himself. "As a bounty hunter. After the Batys [an android husband and wife], there won't be any more. Not after this, tonight."

Sadly, in the end, he resigns himself to his morally questionable work, following the advice of Mercer, a religious icon who appears to him in visions. Mercer explains:

"You will be required to do wrong no matter where you go. It is the basic condition of life, to be required to violate your own identity. At some time, every creature which lives must do so. It is the ultimate shadow, the defeat of creation; this is the curse at work, the curse that feeds on all life. Everywhere in the universe."

The same rationalization returns at the end of the novel as Deckard reflects on his new conviction (resignation?) to his wife:

"Do you think I did wrong?" he asked. "What I did today?"
"No."
"Mercer said it was wrong but I should do it anyhow. Really weird. Sometimes it's better to do something wrong than right."
"It's the curse on us," Iran said. "That Mercer talks about."

These passages haunt me. I'm terrified that anyone could ever conclude that they’re true.

I'll admit, I often feel exactly like Deckard. I have a mortgage and other expenses that never go away. The job market isn't always great. So when my boss demands unquestioning obedience or threatens termination, I feel trapped.

But does that make Mercer right? Are we doomed to do what we hate, what we feel is wrong? Is that the consequence of living in society—the curse that feeds on all life?

I hope with every part of me that it’s not.

When otherwise good people decide they must violate their conscience at work because “that’s the way the sausage gets made,” society begins to slide. We make a mess of things.

Sure, sometimes we have to suck it up and do things we don’t enjoy. That’s fine when the tasks are benign. But when they violate our values and carry real consequences, we have to stand up and say no.

Most things programmers are required to do never rise to the level of evil involved in terminating sentient life forms, but we are still forced to act against our convictions every day. So much of what we do is contrary to what we would choose for ourselves. We are forced to:

• work in distracting open offices, when working at home is more productive.

• complete single-day tasks when we would rather tackle month-long projects and determine the tasks ourselves.

• agree to unrealistic deadlines.

• forgo important planning, research, and prototyping.

• optimize our work to pointless, counterproductive metrics.

• persist in unfruitful circumstances (with people or projects with which we are a poor fit).

• use wasteful and bureaucratic tooling and processes.

• ask permission to install important software on work laptops.

• use specific operating systems instead of the systems we are most comfortable with.

The list could go on forever. Some may disagree that these examples constitute moral dilemmas, but the slope is slippery, and when every request goes unquestioned, we end up as wage slaves—without identity, without careers to shape or be proud of. We share Deckard’s fate:

“...everything about me had become unnatural; I’ve become an unnatural self.”

“Yes, he thought, that’s what it is: I’ve been defeated in some obscure way.”

“I’m a scourge, like famine or plague. Where I go the ancient curse follows. As Mercer said, I am required to do wrong. Everything I’ve done has been wrong from the start.”

Do I refuse to do all the things I listed above? No. I pick my battles to avoid getting fired. Sadly, I agree to way more than I should. We all do. As a result, we have given up a lot of territory. But, we need to find ways to start taking it back.

One thing is certain: to avoid the fate of PKD’s anti-hero, amidst the pressures designed to force compliance, we have to draw lines we won’t cross. If we don’t, we’ll lose ourselves. As hard as it is to stand up against compulsion, the alternative is far worse.

We can do it... right? We have to.

And more to the point: if an android isn’t hurting anyone, can’t we just let them be? Do we really gotta shoot 'em?

A joke memorandum from a fictitious organization that might as well be true, given my experience being forced to do Scrum.

MEMORANDUM
To: Scrum Masters
From: Scrum Managerial Research Institute
Date: 02-25-2025
Subject: Tips for Ensuring Scrum Compliance

Introduction
At Scrum Managerial Research Institute, we understand the challenges Scrum Masters face when dealing with team members who exhibit resistance to Scrum. Such individuals often present ideological objections, consume valuable time, and disrupt team harmony. This memo provides clear, actionable strategies to ensure compliance without the need for prolonged debates—so you can get back to work.

1. Invoke Authority
Remind team members that Scrum is not up for debate. Clearly communicate that the decision to adopt Scrum was made at higher levels in the organization. If objections persist, direct team members to their reporting chain. This removes you from the argument and reinforces organizational alignment.

“This isn’t my call; leadership decided this. If you have concerns, take them up with management.”

2. Skip Retrospectives
Retrospectives can devolve into ideological debates. If engineers are not willing to engage constructively—by only attacking Scrum itself—your only option is to suspend the practice. Until engineers can focus on working within the framework, sadly, they’ll have to forgo the benefits they would otherwise gain from incremental improvement.

3. Tighten the Leash
Strict adherence to the Scrum Guide is required to remove ambiguity and quash deviations. Here are a some suggested actions that can help right the ship:

• Run Scrum Meetings Yourself: Eliminate opportunities for derailment.

• Enforce Rules in Tools: Add required workflow steps and fields to Jira.

• Define Done in Detail: Draft a detailed, non-negotiable Definition of Done to ensure standards are upheld.

• Take Attendance: Enforce meeting participation to ensure team accountability.

• Attach Consequences to Carry-Over Stories: If work isn’t completed within the sprint, establish tangible repercussions.

Consistency is key. Deviations signal that Scrum itself is negotiable.

4. Maintain Control
As the gatekeeper of Scrum tools and processes, you hold the leverage:

• Don’t Negotiate: Avoid debates with developers. Keep interactions brief and to the point.

• Stay Unflappable: If complaints arise, disengage politely. Example: “I’ve got something else to attend to. You’ll excuse me?”

5. Escalation
When compliance remains elusive:

• Refer Developer Objections to HR or Management: Clearly communicate that you are enforcing an established industry standard practiced in thousands of companies worldwide.

• Frame the Issue as Non-Personal: “This isn’t about you or me—it’s about following proven, universal standards.”

Conclusion
While it may feel uncomfortable, strict enforcement of Scrum is sometimes necessary. Scrum only functions when it is implemented in its entirety. Over time, even the most stubborn team members will come to appreciate the discipline and structure you bring to their work. Until then, remain firm, professional, and consistent.

Work isn’t always fun—that’s why they call it ‘work.’

Scrum Managerial Research Institute

(Scrum Planning Meeting)

Senior Programmer: Are those Scrum poker cards I see?

Junior Programmer: Why, yes.

Senior Programmer: Very Nice. A full deck?

Junior Programmer: Yep, Fibonacci from 1 to 34.

Senior Programmer: Do you like magic tricks?

Junior Programmer: Sure!

Senior Programmer: Now these are just story points right? Not hours?

Scrum Master: We only do story points here, never hours!

Senior Programmer: Very good! OK, pick a card and before your very eyes, I'll turn the number on that card into hours.

Scrum Master: Impossible, they don't equate. Apples to Oranges. In Scrum we don't do time estimates.

Senior Programmer: Have you picked your card?

Junior Programmer: Yep, it's the number 2.

Senior Programmer: (taking the card in one hand) Okay! Now I only need three things from you my good Scrum Master. The team size, the sprint length and the team velocity.

Scrum Master: You know all that. Two programmers, 2 week sprints, and 20 points/sprint.

Senior Programmer: Very good. Watch me closely now at the whiteboard. I'm going to do what no magician ever does and show you precisely how my trick works.

(Writes: "2 team members X 40 hours/week X 2 weeks/sprint = 160 hours/sprint")

Scrum Master: (His expression changes from amusement to irritation)

Senior Programmer: OK, we are almost done now, watch closely.

(Below the first line he writes "160 hours/sprint / 20 points/sprint = 8 hours/point")

Scrum Master: OK, now I think our planning meeting is starting to get off track.

Senior Programmer: But we're almost done! (Holding up the Scrum poker card with the number 2 on it) Now tell me dear programmer, what is the number on your card?

Junior Programmer: It's still a 2.

Senior Programmer: And the number on the board here, what does that say?

Junior Programmer: 8 hours/point.

Senior Programmer: multiplying them together?

Junior Programmer: 16..

Senior Programmer: Hours! 16 Hours! Magically, we’ve transformed your story point estimate into hours. The Scrum Master said it couldn't be done! “Story points have nothing to do with hours”, he said.

Well, It appears we have done the impossible!

Now let's see how well you have learned my trick. How about 1 story point?

Junior Programmer: 8 hours?

Senior Programmer: YES! How about 8 story points?

Junior Programmer: 64 hours!

Senior Programmer: The student has become the master!

Junior Programmer: Thank you! Thank you! (Bowing and blowing kisses to an invisible audience)

Scrum Master: Very funny. You've made your point.

In corporate America, software development is a painful slog. Management is fixated on metric optimization, developers take tickets one after another from a backlog, and work consists mostly of taking code that's already written (legacy code, open source, third-party libraries) and gluing it together. It doesn't exactly make you spring out of bed and race to work in the morning.

Even if a company starts out with a better culture, it eventually ends up like all the rest. There are just too many MBAs in suits running around applying their Taylorisms. Any resistance eventually succumbs, given enough time and persistence.

For a while now, I've felt trapped inside this mouse wheel and have wondered what the alternatives are. Most recently, I've looked into freelancing sites like Upwork as an escape from the traditional nine-to-five. But to make that happen, I'd have to ramp up consulting in my free time while keeping my day job to pay the bills. Sadly, I'm realizing that after a day of corporate coding, I just don't have the energy left to serve yet another group of people who want me to code for their benefit. Even if I do manage to transition from traditional employment to full-time freelance, I'm not certain I'll feel any more freedom (apart from a bit more schedule flexibility).

So lately, in the evening—when I should be freelancing—I've been researching the Zig programming language just for fun, because it's cool. I'm enamored with the level of autonomy and innovation that community has achieved. They tackle big, long-standing problems in unique ways. They’re trying things that could have a big payoff—the kind of work a typical software manager wouldn't let you touch with a ten-foot pole because of the perceived risk. It’s exactly the type of work I wish I was doing!

This got me thinking. I have an extra tool in my toolbox that I'm not using aggressively enough: open source software (OSS).

OSS development is my chance to be in charge—to achieve the mastery, purpose, and autonomy that form the foundation of intrinsic motivation.1 At work, I take orders; in the OSS world, I do what I want.

The secret of OSS, and the way it sidesteps traditional capitalist pressures, is that you give it away for free. To some, this may seem foolish. But it's what gives OSS its magic powers.

Because it's free, OSS can be whatever you want it to be. No one can demand anything, and it doesn't have to find a place in the market. No one is paying for it, so users only have two options: take it or leave it. There's a lot of power in that position.

So while I do the boring work of gluing code together at work, the interesting stuff is being done elsewhere. OSS is one of those places—where contributors are digging into new algorithms, building frameworks, and writing new languages.

If things go well with an OSS project, you can even turn a profit. If you manage to get wide enough adoption, people start wanting you to stick around for a while—they become dependent. They start wanting customization, training, and upgrades. If they're excited enough, they may even want to buy some swag.

You've wormed your way into their hearts, and now there actually is a space for you in the market. With OSS, you don't get into the house by ringing the doorbell and giving an uncomfortable pitch on the front porch; you come in through the back door, asking if anyone wants some extra zucchini from your garden. Soon enough, you're all friends.

OSS can even be an effective way to take on the big guy in the neighborhood. I remember fondly how Netscape (eventually renamed Firefox) escaped oblivion to eventually conquer Internet Explorer. Microsoft thought they had the upper hand by bundling IE (at no extra cost) with their operating system. But then Netscape went open source. It was inspiring to watch them take on a giant and beat them at their own game.

Other benefits of OSS include the following:

• You can take it with you when you switch jobs.

• You can neglect it whenever you get too busy.

• If people like it, they may start contributing to it.

• Since it's something you choose, it's likely to be interesting—otherwise you wouldn't have chosen it.

• It allows you to build a portfolio of code you can demonstrate.

• You get good karma from sharing with the world.

• It can benefit you at your day job.

• If someone else is building something that is close to what you want, you can contribute to their project instead of starting something from scratch.

There’s a part of me that wishes the world worked more like OSS. If everyone built what they were passionate about and shared it freely, maybe there would be enough to go around, and you wouldn’t need to buy anything. Money would be unnecessary, and no one would feel compelled to do someone else’s bidding to make a living. When it comes to software, we're pretty close to that reality. There’s an open source version of pretty much anything you could ever want. If you have some hardware and the internet, you can download OSS and be off to the races. You don’t spend a penny. Is there a version of that for everything? That’s utopia in my opinion—an open source world.2

The bottom line is, I think this is what I need to maintain my mental health. After working for the man all day, in the evening I only have enough motivation to build something I totally control. If I can't pick my project, my stack, my tools, and my pace, then I simply don't have it in me to open up emacs again. It feels too much like the same old exploitation in slightly different clothing. I end up watching Netflix instead.3 So I'm officially modifying my trajectory. Instead of trying to transition to freelancing to gain some intermediate freedom and eventually start a company, I'm going to keep my day job and work on OSS at night. Eventually, I hope one of my projects will gain enough traction to bring in some extra cash. But in the meantime, I can use what I'm building for myself and share it with the world. That alone might keep me satisfied for a while. One can hope.

Some people think programmers should only do what they're told—one ticket at a time. Nothing extra.

Scrum has inscribed this sentiment into their official guide: the Product Backlog “is the single source of work undertaken by the Scrum Team.”1 And most engineering managers are careful to keep programmers locked out of the backlog—except for pulling and completing items exactly in the order they're given.

But, if you take this sentiment seriously, you're stuck. You're doomed forever to march to the beat of someone else's drum. The fast track to an unfulfilling career.

Thankfully, there's a simple way to break out of this trap: the shadow project. A shadow project is work you do off the books, on your own initiative. It's something you want to do, for your own reasons.

When you get a hankering to fix something, try something new, or learn something that might help you down the road, fire up a shadow project. Don't ask; just do it.

Forget the backlog.

Luckily, programmers are uniquely equipped for doing shadow work. We don't need special equipment or capital to run our experiments. We can run them on the computers we already have. We don't have to present the ROI or ask for budget to acquire new machinery. We are free to try anything we like, and with so much free software available, it's often as simple as typing 'apt install'.

Of course you'll be picking something that helps the business too. But that's not why you do it. You do it to better your position, make your life easier, or increase your future prospects. Backlogs focus on what other people want. Shadow projects restore the balance. They let you take the wheel for awhile and establish mutual benefit—yours and the company's.

It probably goes without saying, but while you're working on a shadow project, you don't tell anyone. Don’t put a ticket into Jira. What they don't know can't hurt them, right? I know it probably sounds subversive (to be honest, that's part of the fun). But is it really? You're working for the good of the company, in a way that will motivate you far more than working from a never-ending list of tasks. This way, you'll be far more productive.

Just because your manager doesn't understand this concept, doesn't mean you should rot away at your desk updating Jira. Doing shadow work is like pretending your manager actually does know how to motivate you ("Sure! I'd love to research a new language. Thanks!" "A little time for some clean-up work? Don't mind if I do.") and delivering the superior results they don't deserve. Who knows, it may even get them that promotion they are in no way qualified for.

Here's another way to look at it: shadow projects are a way to diversify. If you only do what you're told, you're putting all your eggs in one basket. You're counting on your employer to direct your efforts in a way that will be good for you long term. You're totally dependent on them. I'm much more comfortable taking my fate into my own hands and working on several fronts at the same time. Some sanctioned stuff and some secret stuff. If the sanctioned route works out, then great (for whatever reason, that's rarely the case for me). But if it doesn't, I have other irons in the fire.

Additionally, shadow projects fill an organizational gap. Because of their narrow focus and lack of context, backlogs leave many important things undone, things that programmers are acutely aware of. When you do shadow projects, you're naturally drawn to those neglected areas. By doing yourself the service of addressing things you find painful, you're actually doing the organization a service as well. These are exactly the things your organization needs to address.

Shadow projects can be anything. Sometimes they're directly related to the customer: a new feature or a GUI to hide a tricky command-line. Sometimes they focus on making your day-to-day life easier: some elisp code, a new plugin for your editor, or something to make Jenkins go faster. What's important is to trust yourself to be the guide. If you feel pain, it's relevant. You don't have to stuff it down anymore.

Another reason shadow projects should be exciting to you personally, is so they are interesting enough to motivate you to do them (secretly) alongside your normal work. Many of my shadow projects are moon shots—ideas that are radical, but if they work, they can make a dramatic difference. I've found going after big things is the best way to keep me interested.

Example Shadow Projects

For inspiration, here are a few shadow projects that have turned out well for me:

• Using vagrant and/or docker to create development environments that match production, which eventually turned into a way to create repeatable production environments. (This is common now, but back when I started trying this approach, it was more radical)

• Exposing C code as modules to other languages (ex. gambit, python, C++, zig) to make the system more scriptable—especially useful for writing tests.

• Building an A/B partitioning scheme for an embedded Linux device. Each update is an OS image that's installed to the inactive partition—which then becomes the active partition.

• Converting complicated makefiles and visual studio projects to cmake, which can then automatically generate makefiles, visual studio projects and much more.

• Building gameplay components for level designers in a visual scripting language they were already using, to allow them to design level functionality themselves, instead of having to rely on developers to script it all.

• Using python to generate C code for state machines instead of coding them by hand.

• Investigating literate programming tools to help documentation and code stay in sync, which eventually led to an exciting open source project: https://github.com/adam-ard/organic-markdown

• Adding parallelism to Jenkins builds to take them from hours to minutes.

Looking back, I realize some of my best projects were shadow projects. Lots of good feelings. I'll spare you the details of my failed efforts (but even failures teach you something).

Here are some additional things to keep in mind as you navigate the shadow lands.

Stay Strong, Stay Quiet

With shadow projects, it's rarely useful to tell anyone what you’re doing until you're completely done. That way, if it doesn't work out, you don't have to bring it up at all. No one's the wiser, and people don't start getting the idea you're addressing your own needs concurrently with their priorities (even though you are).

Remember to make at least a little progress on something in Jira every day so you have something to report in morning stand-ups. Otherwise, people might start asking questions and you'll be forced to reveal your stealth project. At which point, they'll start a pressure campaign to make you stop. ("We don't have time for that right now." "Can you make a ticket for that, so we can (de)prioritize it?" "Let's get your current tickets done first.")

Once a shadow project shows promise, and you have some real working code to show off, then you can take a stab at sharing it—perhaps first with a trusted colleague or maybe more widely. Whatever you think gives your idea its best showing. Trust your intuition.

How much working code you need before sharing depends on your goal. How hard is it going to be to convince other people that your idea is viable? If you're dealing with more stubborn coworkers, it might be best to wait until you've implemented a lot of it. Then you can say, "If you don't believe me, here it is. I already wrote it."

If you're dealing with coworkers that are easier to engage, just a little code or research might do the trick. Every situation is unique.

A Cup of Rejection with a Pinch Glory

From the beginning you should expect that nine out of ten shadow projects won't go anywhere, at least not at first. You either won't find them worth presenting or they'll be rejected (by your boss, the team lead, and/or the rest of the team). That's OK! Just file it away for now. You'll have chances to bring it up again down the road—especially if the problem you're trying to solve is painful to others as well. Also, now you've established yourself as a pioneer of the alternative path. People will remember you. They'll come to you in the future when they're finally ready for a change. But no matter what happens to the project itself, you'll retain what you've learned and be a better engineer for your effort.

And what about the one in ten ideas that do get accepted? They can totally change your career. When you manage to get people onboard, opportunities open up. As a result of shadow projects, I've been offered positions on other teams, shifted to new specialties, been saved from getting fired, and maintained connections that have led to future opportunities. In all honesty, I don't know where I'd be in my career without my shadow projects. They've made all the difference.

Some Honest Talk

I'd be lying if I said that shadow projects don't come with some risk; you never know how management is going to respond to someone who goes rogue occasionally. The worst case scenario is you get fired. Most of the time, though, that doesn't happen. Someone who does extra work, for the benefit of the company, is hard to get mad at—even if they are a little subversive. Most managers are smart enough to appreciate free work.

This is how I think about it. If a shadow project gets me fired, I am likely working for a control freak. It's unlikely I'll ever be happy working for a control freak, no matter what I do. So, as difficult as it may be in the moment, getting fired is probably my best outcome; it gets me on to working somewhere with more potential. For that reason, shadow projects are a risk I'm willing to take. I realize that not everyone has the same risk tolerance as me though, and some may see a rare loss of employment offset by occasional moments of shining glory as an unacceptable trade-off. I respect that. The goal is to make work better. If a shadow project is just going to tie you in knots, it's probably not for you.

Are you game?

But if you're ready for an adventure, and your job feels like an endless stream of uninspiring errands, shadow projects might be your thing. They’re not just a way to escape monotony; they’re a way to reclaim agency in your career, sharpen your skills, and discover new opportunities. So proceed with caution, embrace the challenge, and enjoy the ride—because sometimes, the best work happens in the shadows.

In software companies, management lets precious little control fall to programmers. They gobble it up themselves. This is a big problem! It turns programmers into assembly-line, knowledge workers—managed by tasks rather than projects or delegated responsibilities.

In this desert of autonomy, one of the saddest things you'll see is programmers fighting over the few crumbs of power that happen to fall from the table.

Of course, if programmers had access to real power, they'd stop fighting immediately. Who has time to wrestle over mere tokens of control when there are actual responsibilities to attend to?

But, conditions being what they are, software engineers ache from a lack of autonomy, a state that drives them to a handful of micro-power-grabbing behaviors:

Land Grabbing

When some question arises, such as which XML library to use, or package manager, or documentation tool, developers race to set up camp first in the new territory. Frantically, they research, make suggestions, write code samples, often on their own time.

This is all in hopes of being put in charge of this tiny decision. A kind of squatter's rights—to become the new documentation tooling czar or XML parsing king. Feel. The. Power.

This frenzied competition is unnecessary. Undecided questions should fall to individual teams; think states' rights. No need to standardize. Programmers will naturally converge on the best solutions while still leaving room for individual circumstances. We're better off sharing these decisions—no czars or kings necessary.

Code Review Camping

For most developers, code reviews are their only chance to flex the muscles of compulsion. Because they can hold a pull request hostage for any reason at all, sadly, many are all too willing to take the opportunity.

Perhaps they view it as their chance to show commitment to a greater cause or show they are ready for a greater responsibility. Or maybe it's simply because, in that shining moment, they're the boss; their vision is most important. Whatever the reason, every detail must be scrutinized. Even adjacent code must be scrubbed, because "we might as well, while we are in there." Suddenly they’re Anna Wintour and you’re the intern, grabbing coffee and picking up clothes from the dry-cleaner.

I honestly think this is the reason so many developers religiously defend the practice of code reviews, no matter how inefficient they are. It's their only chance to feel respected. I understand; but I hate it. I look forward to a time when we can quit this stupid game.

Committee Forming

Power-starved developers often look to form committees to wrestle some control back. Architecture committees are the most common. However, this rarely gives developers any extra power from above. It only consolidates the little power that remains into the hands of an "anointed" few.

The result is added bureaucracy—extra standards, layers of pre-approval, and bottlenecks that slow down decision-making. Committees add more friction than value.

"Mentoring"

I cringe when someone says they're skilled at mentoring. It feels so paternalistic. First, it assumes there are only two groups of programmers: teachers and learners, parents and children, those who know and those who don't. Second, it positions the speaker as one who knows, placing them above the rest.

I'm sure for some this is an innocent statement about a desire to teach, but I'm suspicious that more often than not it's a political maneuver: Hey boss. Send me the juniors. I'll tell 'em what to do. Lemme take that off your plate.

I, for one, have no interest in being mentored. I'll collaborate with anyone, but if someone wants to pat me on the head and tell me how the world really works, they can give their blessed knowledge to someone else.

Overzealous Team Leading

Team Lead is the only non-management role allowed to boss other programmers around; and boy do they! By the time they get to be a lead, many are so thirsty for responsibility they drink it all up. Any minor technical issue (and at their level, most issues are minor) must be pried from their white-knuckled, death grip.

Curly brace position, tabs or spaces, functional vs. OOP, raw SQL vs. ORM, Jenkins vs. CircleCI. Don't even ask; the Team Lead's going to make that decision. They're not letting go. The Team Lead can be more stubborn than anyone else you report to. They've spent years as a peon and they'll be damned if anyone's going to take a slice of their new shred of dignity.

Sometimes you'll catch them hunched under their desk, clenching their fists, chanting their mantra: "mine... mine... mine..."

We Are Better Than This

I’ve fallen prey to these behaviors as much as anyone else; I can’t judge. But, I think we can do better.

Programmers are natural self-organizers (look at the open source movement). We don't need to hoard control. We don't need to tell each other what to do.

I know we’re starving for autonomy, something to call our own. But the ways we've chosen to satiate our hunger will never bring long-term satisfaction. They only distract us from making a real play for control.

We can be better than our circumstances; we can share our (admittedly limited) power evenly across self-managing individuals and teams. We don't need team leads or committees. We can stop the land-grabbing and the mentoring. We can even trust each other enough to forgo excessive code review requirements and pre-authorizations. We can work as peers, allowing each other an equal portion, and stop wasting energy grasping at crumbs.

NOTE: The mobile version of this article doesn’t format code sections properly. Try the desktop version instead.

I like my code DRY (Don’t Repeat Yourself)—no boilerplate, no repetition. But there’s always a handful of things I can't clean up. Literate program helps me scrub out those last few stubborn repetitions. Because it's basically a pre-processor, Literate programming can DRY out things that no programming language can. Want to write your company's copyright notice once and reference it in all your source files? Want a project name variable that you can reference across your project? Literate programming is up to the challenge.

Here1, I reuse a copyright notice in several files. If I ever need to update it, I change it in one place and run ‘omd tangle’; it gets changed everywhere.

File: main.md

# My Example File

## Here is my copyright notice

```C {name=copyright}
/*
 * Copyright (C) 2024 Adam Ard
 *
 * Permission is hereby granted to use, copy, modify, and distribute
 * this code for any purpose, with or without attribution.
 * This code is provided "as is", without warranty of any kind.
 */
```

## Files

Here are two C files with some mildly interesting example code. Notice how they both have a reference to my copyright in them.

```C {tangle=file1.c}
@<copyright@>

int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);
}
```

```C {tangle=file2.c}
@<copyright@>

int is_prime(int n) {
    if (n < 2) return 0;
    for (int i = 2; i * i <= n; i++) {
        if (n % i == 0) return 0;
    }
    return 1;
}
```

Now if I run ‘omd tangle,’ Organic Markdown spits out my files:

terminal output:

$ ls
main.md

$ omd tangle

$ ls
file1.c  file2.c  main.md

$ cat file1.c
/*
 * Copyright (C) 2024 Adam Ard
 *
 * Permission is hereby granted to use, copy, modify, and distribute
 * this code for any purpose, with or without attribution.
 * This code is provided "as is", without warranty of any kind.
 */

int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);
}

$ cat file2.c
/*
 * Copyright (C) 2024 Adam Ard
 *
 * Permission is hereby granted to use, copy, modify, and distribute
 * this code for any purpose, with or without attribution.
 * This code is provided "as is", without warranty of any kind.
 */

int is_prime(int n) {
    if (n < 2) return 0;
    for (int i = 2; i * i <= n; i++) {
        if (n % i == 0) return 0;
    }
    return 1;
}

To make life even easier, I add a ‘copyright-year’ variable to a yaml block at the top of the markdown file. Then I can reference it in my copyright code block:

main.md

---
constants:
  copyright-year: 2024
---

# My Example File

## Here is my copyright notice

```C {name=copyright}
/*
 * Copyright (C) @<copyright-year@> Adam Ard
 *
 * Permission is hereby granted to use, copy, modify, and distribute
 * this code for any purpose, with or without attribution.
 * This code is provided "as is", without warranty of any kind.
 */
```

When 2025 comes, I’ll simply change the year in the yaml header, and run ‘omd tangle’ again. All the files will get updated.

Something else I like to do is add the project name to the yaml header block. Then I can use it all over the project. Below, the filenames, executable name, code blocks and documentation all use the project-name variable defined in the yaml header block:

main.md

---
constants:
  copyright-year: 2025
  project-name: dry-example
---

# My Example File

## Here is my copyright notice

```C {name=copyright}
/*
 * Copyright (C) @<copyright-year@> Adam Ard
 *
 * Permission is hereby granted to use, copy, modify, and distribute
 * this code for any purpose, with or without attribution.
 * This code is provided "as is", without warranty of any kind.
 */
```

## Files for the @<project-name@> project

Here are four C files with some mildly interesting example code I got
from ChatGPT. Notice how they all have a reference to my copyright in
them.

```C {tangle=@<project-name@>-1.c}
@<copyright@>

int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);
}
```

```C {tangle=@<project-name@>-2.c}
@<copyright@>

int is_prime(int n) {
    if (n < 2) return 0;
    for (int i = 2; i * i <= n; i++) {
        if (n % i == 0) return 0;
    }
    return 1;
}
```

```C {tangle=main.c}
@<copyright@>

#include <stdio.h>

int factorial(int n);
int is_prime(int n);

int main() {
    printf("Running @<project-name@>\n\n");
    printf("factorial of 5: %d\n", factorial(5));
    printf("is_prime 29: %d\n", is_prime(29));
}
```

## Build the examples

```bash {name=build menu=true}
gcc @<project-name@>*.c main.c -o @<project-name@>
```

It all works as expected:

terminal output

$ ls
main.md

$ omd tangle

$ ls
dry-example-1.c  dry-example-2.c  main.c  main.md

$ omd run build

$ ls
dry-example  dry-example-1.c  dry-example-2.c  main.c  main.md

$ ./dry-example 
Running dry-example

factorial of 5: 120
is_prime 29: 1

Using executable code blocks, I can transform the project-name into an include guard2 and use it in a header file. When I add a ‘*’ to the name of a literate reference, the tangle command inserts the output of running the code block instead of inserting the code block itself, as it normally would:

main.md

## A code block to translate input text into `#include guard` format

```python {name=to-include-guard}
for c in "@<txt@>":
    if c.isalnum():
        print(c.upper(), end="")
    else:
        print("_", end="")
        
print("_H", end="")
```

## Header files

```C {name=include-guard}
@<to-include-guard*(txt="@<project-name@>-@<num@>")@>
```

```C {tangle=@<project-name@>-1.h}
#ifndef @<include-guard(num=1)@>
#define @<include-guard(num=1)@>

int factorial(int n);

#endif /* @<include-guard(num=1)@> */
```

```C {tangle=@<project-name@>-2.h}
#ifndef @<include-guard(num=2)@>
#define @<include-guard(num=2)@>

int is_prime(int n);

#endif /* @<include-guard(num=2)@> */
```

console output

$ omd tangle && omd run build

$ ls
dry-example  dry-example-1.c  dry-example-1.h  dry-example-2.c  dry-example-2.h  main.c  main.md

$ cat dry-example-1.h
#ifndef DRY_EXAMPLE_1_H
#define DRY_EXAMPLE_1_H

int factorial(int n);

#endif /* DRY_EXAMPLE_1_H */

$ cat dry-example-2.h
#ifndef DRY_EXAMPLE_2_H
#define DRY_EXAMPLE_2_H

int is_prime(int n);

#endif /* DRY_EXAMPLE_2_H */

Now that’s some DRY code! If you’d like to learn more about Organic Markdown, checkout the github project: https://github.com/adam-ard/organic-markdown. The main readme has more instructions and links to additional documentation.

Here is the full code listing for reference. Happy Literate Programming!

main.md

---
constants:
  copyright-year: 2025
  project-name: dry-example
---

# My Example File

## Here is my copyright notice

```C {name=copyright}
/*
 * Copyright (C) @<copyright-year@> Adam Ard
 *
 * Permission is hereby granted to use, copy, modify, and distribute
 * this code for any purpose, with or without attribution.
 * This code is provided "as is", without warranty of any kind.
 */
```

## A code block to translate input text into `#include guard` format

```python {name=to-include-guard}
for c in "@<txt@>":
    if c.isalnum():
        print(c.upper(), end="")
    else:
        print("_", end="")
        
print("_H", end="")
```

## Header files

```C {name=include-guard}
@<to-include-guard*(txt="@<project-name@>-@<num@>")@>
```

```C {tangle=@<project-name@>-1.h}
#ifndef @<include-guard(num=1)@>
#define @<include-guard(num=1)@>

int factorial(int n);

#endif /* @<include-guard(num=1)@> */
```

```C {tangle=@<project-name@>-2.h}
#ifndef @<include-guard(num=2)@>
#define @<include-guard(num=2)@>

int is_prime(int n);

#endif /* @<include-guard(num=2)@> */
```

## Files for the @<project-name@> project

Here are four C files with some mildly interesting example code I got
from ChatGPT. Notice how they all have a reference to my copyright in
them.

```C {tangle=@<project-name@>-1.c}
@<copyright@>

#include "@<project-name@>-1.h"

int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);
}
```

```C {tangle=@<project-name@>-2.c}
@<copyright@>

#include "@<project-name@>-2.h"

int is_prime(int n) {
    if (n < 2) return 0;
    for (int i = 2; i * i <= n; i++) {
        if (n % i == 0) return 0;
    }
    return 1;
}
```

```C {tangle=main.c}
@<copyright@>

#include <stdio.h>

#include "@<project-name@>-1.h"
#include "@<project-name@>-2.h"

int main() {
    printf("Running @<project-name@>\n\n");
    printf("factorial of 5: %d\n", factorial(5));
    printf("is_prime 29: %d\n", is_prime(29));
}
```

## Build the examples

```bash {name=build menu=true}
gcc @<project-name@>*.c main.c -o @<project-name@>
```

My wife's gotten into Christmas puzzles this year. She leaves them half-finished on a table in the family room. As soon as one is finished, she starts the next. So, naturally, I sit down occasionally to hunt for a piece or two—what could possibly go wrong?

Four hours later, I realize it's 2:00 am and I've done nothing else with my evening and I swear I'm coming to bed in one second. Just one more piece to finish the cat... I'm so close. Here kitty kitty... let’s get you home. ARE YOU TOO GOOD FOR YOUR HOME?!

It goes without saying, I've spent a lot of time lately on these heroin-soaked devils and I'm starting to think of everything in terms of Christmas puzzles (the same way too much Tetris makes everything feel like a block I need to find a really good place for).

Here are a few life lessons from my puzzle-frenzied mind. May they serve your puzzle addiction (and maybe your life in general) as well as they have mine.

A Foundation

When I start a puzzle, my mind has to build a foundation first. Subconsciously, it starts cataloging colors and locations. I may not be placing lots of pieces, but that doesn't matter. If I stick with it through the slow phase, pretty soon I start recalling features of the puzzle from memory. Mystically, I'll see a piece and say, Oh, that goes right here. That’s when the momentum picks up.

Progress

I work and I work and it feels like I've hardly made progress at all. Then, out of nowhere, after many hours I can't fully recall, I’m almost done.

To notice my progress, I have to force myself to stop and look around. Sometimes I’m so deep in the puzzle I need my wife to tell me how much progress she’s seen me make (“You’re doing too much; leave some for me!" “You have to stop; you have a problem.” ) to believe I am really getting somewhere.

Fatigue

It may seem obvious, but it’s amazing how often I try to do a puzzle when my brain is too tired. It's best to stop and sleep a bit. What takes hours with a tired brain can be accomplished in minutes with a fresh one.

Companionship

It's useful to have someone else working on the puzzle with me—for many reasons: I tire less quickly, we can team up in various ways, and it's more entertaining overall.

Beginner's Mind

Pieces that seem like they must fit—perfect color and shape—often belong somewhere else entirely. I need to keep a beginner's mind and be open to different interpretations.

Nothing's Perfect

Sometimes a piece falls on the floor, and my dog eats it—oops. But I have to be OK with that. Nothing in life is perfect. Some of our puzzles have missing pieces, but so what? They're still worth doing. Perfectionism be damned.

Let the Puzzle Decide

I often get stuck looking for one piece or finding a place for another. I have to stop forcing the work and let the puzzle unfold how it wants to.

Martin Fowler describes three categories of code ownership:1

• Strong Code Ownership: Each module (classes, functions, files) is assigned to one developer, who exclusively makes changes. Others must request changes through the owner, often by submitting patches (or pull requests).

• Weak Code Ownership: Modules have owners, but anyone can modify them. Owners monitor changes to their modules and collaborate on significant edits.

• Collective Code Ownership: The team owns the codebase collectively, allowing anyone to make changes anywhere. Advocates emphasize team ownership over individual control.

Later in his article he says, “Of the three the one I really don't like is strong code ownership” and admits a preference for “the dynamics of a collective code ownership team—particularly in the context of Extreme Programming.” The agile community has followed suit with that opinion. On most teams, anyone can edit anything.

As Fowler points out, this model works well if you use the collaboration practices from Extreme Programming (XP). But I believe the industry was too hasty to dismiss strong code ownership, which provides its own set of benefits2 (especially when run like an open source project). It can be just as effective as XP and sometimes, when considering the individual preferences and talents on your team, it may be the better option.3

Ownership in Xiaogang

Consider the story of how China transformed itself economically by embracing the previously forbidden practice of ownership—allowing workers to reap the direct benefits of their labor.

In the 70’s, in China, there was no concept of private property. Farmers worked on collectives where the government took all that was produced and divided it equally among all families. One such collective was located in the village of Xiaogang where residents were struggling to grow enough food, resorting to begging.

Realizing that something had to change, secretly, farmers in Xiaogang parceled up the land among the village families, allowing each to keep at least some of their own harvest, if it was bountiful enough. They risked death to try their illegal experiment, but in the end it was successful. It netted a larger harvest “than in the previous 5 years combined.”4

What was the difference? The rules of the game. In a word: ownership. Where before:

There was no incentive to work hard — to go out to the fields early, to put in extra effort5

Now the village was motivated. It thrived. After the secret arrangement, villagers became masters of their own fate.

It was the same land, the same tools and the same people. Yet just by changing the economic rules — by saying, you get to keep some of what you grow — everything changed.6

Needless to say, it was not possible to hide a 5X productivity increase from the government. But luckily, their actions where not viewed as treason but instead as instructional. Among other reforms, China implemented the model of Xiaogang’s partially privatized farm nationwide and “China’s economy started to grow like crazy. Since 1978, something like 500 million people have risen out of poverty in China.”7

Ownership in Software Development

Software teams can reap the same benefits of ownership as Xaiogang. Obviously, developers don’t own their code in a legal sense; when they leave the company, they don’t take source code with them and use it elsewhere. But they can still own the code in ways that yield the motivational benefits achieved by the Chinese Farmers of Xiaogang. Parceling up the codebase among team members, in a strong code ownership arrangement, makes everyone a custodian or steward over a piece of the product. Individual programmers can be guardians of their piece’s design, testing, and quality. When evaluating pull requests, their detailed knowledge and investment make them rigorously attentive. All code must conform to their personal standards to be acceptable.

There are many benefits of strong code ownership; below are a few:

• Mastery of a domain : Focus on a narrower section of code makes it easier to master.

• Pride in workmanship : It’s easier to look back and be proud of good results in your stewardship—the code over which you were solely responsible.

• Respect from peers : It’s easier for others to appreciate good results in your stewardship.

• Joy of providing customer value :  It’s easier to see how your work directly effects the customer, as they interact with the code from your stewardship.

• Code cleanliness: With gatekeepers, code changes are rigorously vetted and stay true to original design.

• Personal portfolio : It’s easier to collect concrete examples of your work and easier for your manager to assess them.

• Higher quality: Programmers tend to take better care of their individual stewardship, better than code shared by everyone. In a 2011 study examining the relationship between code ownership and software quality, Microsoft determined that files with clear ownership had fewer defects.

The Pendulum Always Swings Too Far

Before the agile revolution, strong code ownership was common. Jeff Atwood’s article from 2005, You Gotta Own It, displays a strong code ownership ethos:

… Renters don't take pride in their homes. Only homeowners do.

… if you do want great software, you have to let the developers own what they’re building. The developers are inevitably the ones who have the most control over the success or failure of the project. Creating an environment where your developers have no emotional attachment to the project they’re working on is a recipe for mediocre software — and job disillusionment.

The notion of "egoless programming" is dangerous and wrongheaded.

…Smart organizations cultivate this sense of ego-driven ownership with an implied trust: they go out of their way to hire smart people, and then they get out of the way.

If you're not working in an environment where ownership is encouraged, either wrest control from the powers that be, or start looking for another job. You gotta own it.8

He quotes Joel Spolsky:

Software, by its nature, is very easy to divide into smaller and smaller components, so it's always possible to divide up responsibility among people and let people own an area. This is probably THE reason why software people love working at Microsoft.9

A lot of good software was built with strong code ownership. We know it works.

But with agile’s rightful rejection of waterfall’s upfront planning, a shift towards shared code ownership came along for the ride. While it did popularize a collaboration model ideal for extroverted programmers—that were perhaps suffering from feelings of isolation—the pendulum swung too far the other way and cut out the introverts—programmers that draw energy from being alone. After agile came, the suffering switched to them.

It doesn’t have to be one or the other. Strong and collective code ownership teams can co-exist in the same organization and service both personality types. (I don’t think it’s a good idea to do both on the same team though) Neither type need be overlooked. Programmers may even benefit from trying out “the other side” once in a while depending on the circumstances.

So, for the sake of suffering introverted programmers everywhere, please don’t discount strong code ownership. It can be just as effective as a well run XP project and, for some teams, it may be superior. On your next project, especially if your team needs a motivational boost, give strong code ownership a try. It may just be the change you need.

Apparently, they just wrapped up the 16th Annual Give Thanks for Scrum Conference.1 (Yes, that's a real thing. I wish it were a joke.) Jeff Sutherland is touting the next evolution of Scrum: Extreme Agile. (Nope, still not a joke. That's really what he’s calling it. Yes, I know there's already an Extreme Programming.) He's all done with "twice the work, in half the time," the measly 4X improvement he claims to get from Scrum. With Extreme Agile (essentially Scrum + AI + magic) he's claiming to get up to a 100X improvement (Nope, not an exaggeration. He really said 100.)

So, let's do the math. Something that takes a normal developer (someone not using Extreme Agile) a full year (~2000 hours), will take 20 hours for one of Jeff's devoted followers--not even a full week's work.

Face. To. Palm.

But everyone knows it's just hyperbole, right? He just means 'going fast' and now 'going really fast'. What's the big deal? The main problem with this laser focus on speed over all else isn't that the numbers are highly suspicious, it's that they telegraph to managers everywhere that Jeff is still their man. Scrum was about speed before, and Extreme Agile is about even more speed now. It's a management dog whistle. Your boss knows they can rely on the fact that Jeff still has his priorities straight. None of this nonsense about craftsmanship or building the right thing. That's just developer speak for, "I want to take it easy, and chase after shiny objects." Jeff sees through that. It won't be long before your boss is saying, "Let's get our guys out there for some Extreme Agile training."

So I've realized (been reminded really) it's not worth fighting any more. In the future, if I'm ever poised to jump down the Scrum-bashing rabbit-hole again, I’m going to remind myself: if it’s not Scrum, it'll be something else. Jeff’s presentation makes that perfectly clear. All my talking about Scrum isn’t going to amount to anything in the long run, because neither developers nor Scrum Masters control anyone's fates at work. Owner is the only position with real power.

And for most owners2, worker autonomy is not on the road-map today or next week or ever, it never was. Scrum isn’t the enemy, low trust work environments are. Owner’s don't care if you bad mouth the process. Why should they? They hold all the cards. They have all the leverage. And even if Scrum goes away, Extreme Agile is close on its heels, or something even worse.

So, I’m ready to stop wasting time arguing about Scrum and start talking about things that can actually move the needle--ways to take power back. I want to start talking about freelancing and/or starting your own business3. That's the only way things will ever change.

Programmers have options, believe it or not. I know the market is tough right now. But AI is changing the game. It can make developers into productivity machines, making freelance work easier and more lucrative. I want to leverage AI for myself, not for my employer--certainly not in some scheme to make development even more frantic like "Extreme Agile."

For starting a small business, recent developments in AI are a stroke of incredible luck. They promise to make it even simpler to replace the business side of things and go it alone. Need an invoice? Ask AI. Need help with marketing materials? Ask AI. And I'm convinced it's only going to get better.

And since I'm in the same boat you are, grinding it out 9-5 for someone else, I want to practice what I preach and start dipping my toes into the freelancing water myself. I'm curious about sites like Upwork or fiverr. I've even seen some places that are paying programmers to produce example code that is later fed to AI models. I'm going to try it all (on the side, so be patient. I've still got a day job) and see if it's worthwhile. Then I'll write about what I discover--about how to use AI or anything else that makes it easier.

AI doesn't have to be an instrument of more corporate pressure; it can be our ticket out of this mess.

If freelance websites aren't a good option, then I'll move on to more traditional networking tactics and write about those as well. Whatever I’ve gotta do.

The purpose of targeting freelancing gigs first is to gain a little elbow room. Side work gives you extra savings and, when you go full-time, extra freedom over your schedule. For some, maybe full-time freelance work will be the ultimate goal; that’s totally cool. For me, it’s a step closer to starting a business and selling my own products--a way to bootstrap myself. Maybe that's interesting to you too.

By documenting my process (I'm going to try this in real-time, instead of after the fact, because I think it will be more informative that way. (I hope I don’t fail; that would be embarrassing)), Rethinking Software can become more than just a place to talk about writing software, but also a resource for any developer struggling to slip the 9-5 handcuffs—a good place for actionable information and helpful conversations. As I gain insight, I’ll post more notes and articles, so it can enlighten your path as well.

Let’s stop waiting for change and start building it ourselves.

Operation Liberate Programmer

First, I pointed out that sprints are problematic because they always repeat back-to-back. They don’t give you a break, and they stress people out. But Scrum advocates were quick to point me to the concept of “sustainable pace.” I guess if I understood that, I could do sprints forever, without a break, and never get tired. Sounds amazing. But I was left wondering why the obvious solution wasn’t acceptable: just taking breaks. Oh well. They know better than me.

Next, I pointed out that daily stand-ups are difficult because they make you feel like you have to justify your work every day, even when you happen to not make any progress. But my Scrum friends reminded me that stand-ups were never supposed to be status reports. They said that an evil elf named Yesterday-today-no-blockers McIntyre spread that lie around the industry long ago, and people have been confused ever since. I guess Mr. McIntyre was pretty influential because he seems to have gotten to every Scrum Master I’ve ever met. I wonder why he is still invited to all the Scrum conferences?

Then I told them that software estimation is problematic. No matter how hard I try, I can’t seem to figure out how long a task is going to take until I’ve gotten my hands dirty and written at least a little bit of code. But the Scrum gurus just scoffed. Scrum doesn’t do estimation; it does sizing, and you should never use time when you are doing sizing. I had no idea there was a difference! When you do sizing, you pick a barnyard animal that best describes the way you feel about your task (I always pick an ass). Then you put all those animals into the magical Jira machine and turn the crank—out pops burn-up, burn-down, (burn-it-all-down?) charts. No estimation needed. So, I was wrong again. They’ve got it all figured out.

Finally, I mentioned the issues I’ve had with giving Product Owners full control of the work. I explained that it doesn’t give developers a seat at the table or treat them like equal stakeholders. They just end up being ticket-takers. It also makes it hard to get approval for any work that doesn’t look like progress to the non-technical Product Owner: planning, refactoring, researching, training, etc. But they got me again. I am so stupid! They reminded me that no Product Owner would ever be so shortsighted. In general, Product Owners are like Santa Claus and think of developers as the children they watch over all year long. They have no other interests in mind. And if ever there was a bad egg Product Owner, the organization would fire them immediately. Because the last thing any organization would want is for developer needs to be ignored (that is why they picked Scrum in the first place! Duh!).

So, they assured me that all developers are in perfectly good hands. That’s why it’s totally OK for the Scrum Guide to give them unilateral, unchecked power over creating and prioritizing all the engineering work.

It turns out that my worry about Product Owners not being technical is not a big deal either. I was assured that everything anyone needs to know about building software is covered very thoroughly in the three-day Scrum certification training that Scrum Masters and Product Owners attend. Thank goodness.

Here, I thought I had found the four core elements of Scrum, straight from the Scrum Guide—the official document from Scrum.org—that were causing problems in the software teams I have been a part of. I thought there wasn’t any way someone could say, “you’re doing it wrong.” But, yet again, I ended up with egg on my face. Because, of course, yet again, I am doing it wrong. No matter how many times I read that guide, I just can’t seem to get its pure meaning through my thick developer skull.

But for those of you that have had the same “pretend” problems with Scrum as me, issues that you could have sworn were making life hard—even though it is just because you haven’t been able to fully internalize the glorious revelations of Sutherland and Schwaber yet—here are four articles that can help you fix the already perfect process your boss and Scrum Master are calling Scrum, that isn’t even close to the beautiful, pure, real Scrum that no one has actually managed to implement yet.

1. Sprints constantly repeat, with fixed lengths and no breaks.

2. Stand-ups are everyday.

3. Scrum depends on estimates (a.k.a. sizing).

4. The product owner has full control over the product backlog.

Scrum's Definition of Done (DoD) is a convenient way for Scrum advocates to punt on resolving any real issues with their process.

If anyone complains that Scrum produces poor results, they have their ready response: The DoD should prevent this; if the work doesn't fit the DoD, it should be rejected; developers are simply not following the process.

Despite the inefficiencies and frustrations Scrum piles on developers, poor results are "impossible." Why? Because the Scrum Master has defined them away—binding programmers to their unholy oath of compliance.1

In their world, poor results don’t exist.

They can’t exist. The DoD forbids it.

These are not the droids you’re looking for.

The Scrum Guide defines the Definition of Done as a shared understanding of what it means for a product increment to be complete—a quality standard ensuring all increments are potentially shippable or releasable. In other words, “nothing ships unless it’s perfect.” Easier said than done.

Here are some common items for a DoD:

• tested

• documented

• reviewed

• no bugs

Good ideas, but unless your process builds them into daily workflows—through TDD, pair programming, or literate programming—they’re just bolt-ons, band-aids to stop the bleeding.

This thinking leads to an ever-growing checklist of ways to reject work: pre-authorizations, design approvals, 100% test coverage, team-wide code reviews, and tedious manual testing phases straight out of the Waterfall era.

An ever-growing bureaucracy. Pure quality theater.

To their credit, they named the DoD well. That’s exactly what it is: a definition—not a solution, not a root cause analysis—just a description of what quality software should look like. Once it's drafted, the team is expected—by decree—to produce only quality output. Nothing else is acceptable. Take what Scrum gave you before, don't change anything about the process, but now get different, higher-quality results. It's closer to the definition of insanity.

It’s a lot like running an apple orchard and claiming your process only produces flawless fruit: no bruises, perfect color, uniform sweetness. But the truth? The orchard just tosses every imperfect apple in the dumpster before they reach the market. Perfect apples at the market say nothing about the process. For all you know, they’re wildly inconsistent at growing good fruit—throwing away nine (or ninety-nine) apples for every one they keep.

What's worse is that corporations that run Scrum do not modify delivery expectations to account for process inefficiency, because they don't believe they exist. They shut their eyes to it. Yet they still demand a hundred apples a day. "Come on, what's so hard about picking a hundred apples a day?" What they don't see, however, (what they don't want to see) are the nine hundred apples that go into the dumpster in the back, while their workers hunt for a hundred apples that meet their criteria.

This way, developers end up doing the extra legwork themselves, if they want to get a reasonable product out of the frustratingly difficult practices of Scrum. Maybe you've heard this before? "If you can't meet your sprint commitments, you're expected to do nights and weekends."

That’s why I call the Definition of Done a punt—a way to dodge fixing real process deficiencies. It shifts all the responsibility for inefficiency to developers and hands them all the blame as well. Because, anyone who questions the system must be a malcontent that doesn’t do Scrum correctly—not someone with valid concerns.

Sooner or later, frustration and exhaustion take their toll. Companies end up with sprints yielding only a couple hundred apples total to choose from. So, definition or no definition, they’re stuck with whatever the system produces—even if only a few features can be considered “good” at all. Developers face a Sophie’s Choice: deliver subpar features or nothing at all.

This is the point when turnover ramps up, fingers start pointing, and scapegoats are born. Wise companies will eventually fire the management responsible for running productivity into the ground, but usually not until a lot of well-meaning developers go down in flames—and long after anyone good has headed for the hills.

It's a sad story I have lived through many times. But the solution is not hard. Ditch the rigid Scrum regimes still ruling the industry and hand control of the engineering process back to the engineers. And I'm not talking about giving control to engineering managers who toe the company line and are just as invested in Scrum as the business. Give control to the engineering team--the developers writing the code--the ones opening up their IDEs, typing in the code, and hitting compile.

Let them organize themselves. They’re the ones who know how to craft the right process for their work—one that naturally delivers better results. Do that, and the Definition of Done won’t matter anymore. The system will simply produce high-quality fruit on its own.

#endscrumin2025

Philosophically, I hold the view that no developer—or any worker, for that matter—should be forced or coerced. Autonomy isn’t just vital for professionalism—it’s the cornerstone of workers’ dignity and humanity.

This is not just a moral argument; it’s a natural law argument—a belief in fundamental, self-evident rights tied to human nature. By nature, workers must have control over their own actions, because they are the ones performing them. It’s the worker’s hand that pounds the nail, types the code, or operates the machinery. It is most natural that they choose how to work. In fact, they can only lose this control through coercion—most often through the fear of being fired.

The Logical Limits of Authority

Some argue that corporate owners hold absolute authority, but logic shows their power must have limits. What if an owner demands the unreasonable—such as working 24-hour days—or insists on unsafe or unreasonable conditions? Clearly, the worker can refuse. In these extremes, worker autonomy is self-evident. But this same autonomy applies much more broadly.

Natural law dictates that all worker action must be voluntary—just as collaboration is voluntary in other relationships, like those between spouses, church volunteers, or friends.

The line between acceptable and unacceptable requests lies between compulsion and persuasion. Workers are under no inherent obligation to comply with any request; they are free to choose based on mutual benefit, not fear of reprisal.

Workers Are Not Property

The corporate notion that an owner’s will always takes precedence over that of the worker’s is fundamentally unnatural. While owners may have legal rights over company property, workers are not property. They are collaborators. As such, their compliance should be earned through persuasion and mutual benefit, not fear of being fired.

When workers defer unquestioningly to their superiors, they give up their natural rights. John Locke, in his Second Treatise, argues:

The Labour of his Body, and the Work of his Hands, we may say, are properly his. Whatsoever then he removes out of the State that Nature hath provided, and left it in, he hath mixed his Labour with, and joyned to it something that is his own, and thereby makes it his Property. 1

When workers mix their labor with a corporation’s resources, they naturally gain a stake in both the process and its outcomes—just as Locke describes. Too many corporations are accustomed to ignoring this natural ownership, ruling with an iron fist and taking all the proceeds. This is unnatural.

What It Looks Like in Practice

In software development—my area of expertise—unrealistic deadlines demonstrate this conflict clearly. Deadlines that lead to burnout or encourage poor workmanship are not mutually beneficial. Developers benefit most from working at a reasonable pace, where they can practice craftsmanship and cultivate mastery.

Developers must push back to safeguard their well-being and ensure quality work. If management can’t align their work expectations with reasonable working conditions, the relationship lacks mutual benefit, and developers should feel empowered to refuse.

Further, programmers must have autonomy over the labor of their hands and minds. They should have the authority to compose their work as they see fit, developing personal skills and competencies along the way. Workers should be judged on their outcomes, not micromanaged on their methods.

When management utilizes pseudo-productivity metrics, like task completion rates, they prioritize owner benefit at the expense of workers’ personal mastery and aspirations. This dynamic is not mutually beneficial—it’s exploitative.

Economic Dependence Worsens Coercion

The most insidious enabler of coercion in the workplace is economic dependence. Many workers live paycheck to paycheck, making the threat of being fired deeply coercive. Debt and reliance on steady income shackle workers, turning them into wage slaves under the illusion of choice. While not compelled by law to serve their employers, they are bound just as forcefully by economic necessity.

The suggestion that workers can simply "quit" if mistreated is naive. Economic dependence gives too much power to corporations. The resulting dynamic effectively creates an aristocratic class of capitalist owners who wield disproportionate power over workers.

Restoring Balance

To restore balance, we must reduce dependence on paycheck-to-paycheck living and adopt healthier workplace governance models. By empowering workers with autonomy and choice, we can reshape workplaces into spaces of mutual benefit, not coercion.