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

by Gene Kim

Cranky Dave frowns. “I’ve been at Parts Unlimited for almost five years, and I can’t believe how the bureaucracy and silos have taken over. You can’t do anything without first convincing a bunch of steering committees and architects or having to fill out a bunch of forms or work with three or four different teams who each have their own priorities. Everything is by committee. No one can make decisions, and implementing even the smallest thing seems to require consensus from everyone. Almost everything I need to do, I have to go up two levels, over two levels, and down two levels just to talk with a fellow engineer!”

Dwayne chimes in. “In Ops, we often have to do the return path—up, over, down, and then back up, over, and down before two engineers can finally work together to get something done.” “I want to bring back the days when a developer could actually create value for someone who cares, easily and quickly,” Cranky Dave says. “I want to build and maintain something for the long haul, instead of shipping the ‘feature of the day’ and dragging all this technical debt around.”

“Simplicity is important because it enables locality. Locality in our code is what keeps systems loosely coupled, enabling us to deliver features faster. Teams can quickly and independently develop, test, and deploy value to customers. Locality in our organizations allows teams to make decisions without having to communicate and coordinate with people outside the team, potentially having to get approvals from distant authorities or committees so far removed from the work that they have no relevant basis to make good decisions,” he says, clearly disgusted.

;)

When Maxine sees Tom pull up the Ops ticketing system and create a new ticket, she asks, “What’s this for?” “We need the production logs for Data Hub and its connectors to see if they’re handling traffic or if they’ve crashed,” he responds, filling out the numerous fields. “We can’t directly access production logs?” Maxine asks, afraid of the answer. “Nope. Ops people won’t let us,” he says, typing into the form. “So, someone has to respond to the ticket and copy the logs off the server for us?” she asks in disbelief. “Yes,” he says, continuing to type, obviously very practiced at filling it out. He tabs between fields, types, mouses over to hit the drop-down box, hits the submit button, only to find that there’s still another required field that needs to be filled in. Maxine groans. The Data Hub application that they’re working on might as well be running in outer space or at the bottom of a deep well. They can’t directly access it, they can’t see what it’s doing, and the only way they can understand what’s actually happening is to talk to someone in Operations through the ticketing system.

“In 2010, Risto Siilasmaa was a board director at Nokia. When he learned that generating a Symbian build took a whole forty-eight hours, he said that it felt like someone hit him in the head with a sledgehammer,” Erik says. “He knew that if it took two days for anyone to determine whether a change worked or would have to be redone, there was a fundamental and fatal flaw in their architecture that doomed their near-term profitability and long-term viability. They could have had twenty times more developers, and it wouldn’t have made them go any faster. Erik pauses. “It’s incredible. Sensei Siilasmaa knew that all the hopes and promises made by the engineering organization was a mirage. Even though there were numerous internal efforts to migrate off of Symbian, it was always shot down by the top executives until it was too late. “Business people can see features or apps, so getting funding for those is easy,” he continues. “But they don’t see the vast architectures underneath that support them, connecting systems, teams, and data to each other. And underneath that is something extraordinarily important: the systems that developers use in their daily work to be productive.

“It’s funny: the tech giants assign their very best engineers to that bottom layer, so that every developer can benefit. But at Parts Unlimited, the very best engineers work on features at that top layer, with no one besides interns on the bottom working on Dev productivity.

To get a Phoenix build going, she opened up tickets to what felt like half of the QA and Operations organization and waited helplessly while they worked to get the things she needed.

More and more dependencies, as far as the eye can see, she thinks. There is no place in this whole screwed-up system where you can get anything done. It doesn’t matter whether you’re creating the ticket, processing the ticket, waiting on the ticket, or working the ticket. It doesn’t matter. You’re trapped in a web of dependencies, completely unable to get anything done, no matter where you are.

Over the decades, Maxine has tried to explain to non-technical people how frightening code merges are. Her best description is having fifty screenwriters simultaneously working on a Hollywood script when they haven’t decided who the main characters are, or what the ending will be, or whether it’s a gritty, detective story or a bumbling sleuth with a sidekick. They break up the writing responsibilities between all the writers, and each writer works on their part of the script in isolation, typing away in Word for weeks at a time. Then, right before the script needs to be finalized, all fifty writers get together in a room to merge all their work back together into a single story.

Maxine knows she hasn’t delivered a stirring Henry V Saint Crispin Day rallying speech, but she’s dumbfounded that people aren’t more bothered by this situation. She was hoping someone would yell out, “Hell yes, that bothers me, and we’re not going to take it anymore!” But instead, there’s just silence. We don’t even need guards anymore. We love being prisoners so much, we just think the bars are there to keep us safe.

When it’s not an executive asking for data for a board presentation, even the simplest data requests take six months, as their requests lumber through the Data Warehouse Dev and QA processes.