The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data

by Gene Kim

Punishing failure and “shooting the messenger” only cause people to hide their mistakes, and eventually, all desire to innovate is completely extinguished.

Creating software should be a collaborative and conversational endeavor—individuals need to interact with each other to create new knowledge and value for the customer.

Without constant feedback from a centralized build, integration, and test system, they really have no idea what will happen when all their work is merged with everyone else’s.

Maxine loves coding and she’s awesome at it. But she knows that there’s something even more important than code: the systems that enable developers to be productive, so that they can write high-quality code quickly and safely, freeing themselves from all the things that prevent them from solving important business problems.

Everyone around here thinks features are important, because they can see them in their app, on the web page, or in the API. But no one seems to realize how important the build process is. Developers cannot be productive without a great build, integration, and test process.

Maxine knows that agility is never free. Over time, without this type of investment, software often becomes more and more difficult to change.

She is disheartened by how Parts Unlimited executives, the bridge officers, are so disconnected from the daily work of the “redshirts” in the technology organization.

“Other companies have done this already. I think that anyone who is still paying Kumquat database maintenance fees is simply too dumb to migrate off it.”

Tech giants like Facebook, Amazon, Netflix, Google, and Microsoft give Dev productivity responsibilities to only the most senior and experienced engineers. But here at Parts Unlimited, it’s the exact opposite.”

my favorite is how it was originally defined by Ward Cunningham in 2003. He said, ‘technical debt is what you feel the next time you want to make a change.’

Your teams are able to add features at a rate that the entire Phoenix team should envy. And that is only possible because you pay down technical debt as a part of daily work. It’s a magnificent example of the First Ideal of Locality and Simplicity in our code and organizations.

First Ideal of Locality and Simplicity. We need to design things so that we have locality in our systems and the organizations that build them. And we need simplicity in everything we do. The last place we want complexity is internally, whether it’s in our code, in our organization, or in our processes.

“The Second Ideal is Focus, Flow, and Joy. It’s all about how our daily work feels. Is our work marked by boredom and waiting for other people to get things done on our behalf? Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during a deployment when everything blows up, leading to firefighting, punishment, and burnout? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work?

The Third Ideal is Improvement of Daily Work. Reflect upon what the Toyota Andon cord teaches us about how we must elevate improvement of daily work over daily work itself.

The Fourth Ideal is Psychological Safety, where we make it safe to talk about problems, because solving problems requires prevention, which requires honesty, and honesty requires the absence of fear. In manufacturing, psychological safety is just as important as physical safety.

the Fifth Ideal is Customer Focus, where we ruthlessly question whether something actually matters to our customers, as in, are they willing to pay us for it or ...

I believe my job my job is very simple: listen, do whatever you need me to do to help make you successful, and remove any obstacles in your way.”

When he nods, just as Maxine did with the middle-school girls, she proposes rewriting the code path using functional programming principles. Tom’s test case has a lot of mocks and stubs to simulate the production environment: a configuration server, a database, a message bus, a customer object factory . . . . She jettisons all of them, because those are not areas of the system she wants to test. Instead, she pushes all that input/output and side-effects to the edges and creates unit tests around how an incoming repair order message is processed, how customer data is transformed, and what outgoing messages are sent. She has each thread make its own copy of the customer object. They rewrite each object method into a series of pure functions—a function whose output is completely dependent upon its inputs, with no side-effects, mutations, or accesses to global state.

“That’s not servant leadership, it’s transformational leadership,” Erik says. “It requires understanding the vision of the organization, the intellectual stimulation to question the basic assumptions of how work is performed, inspirational communication, personal recognition, and supportive leadership. “Some think it’s about leaders being nice,” Erik guffaws. “Nonsense. It’s about excellence, the ruthless pursuit of perfection, the urgency to achieve the mission, a constant dissatisfaction with the status quo, and a zeal for helping those the organization serves.

“You know the joke—what’s the plural of ‘developer’?” says Maxine. “A ‘merge conflict.’”

“What the hell have you gotten me into?!” Chris says, fuming at Kurt. “Maggie and Sarah tell me that you’ve proposed to create your own Ops organization inside of Dev?! And that you’ve gotten some sort of exception waiver to start running some new Tier 2 services in the cloud?! I don’t suppose you ever thought to ask me first?”

Just like Norm Kerth says in the Agile Prime Directive, ‘Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.’