The Unicorn Project

by Gene Kim

  I’m sorry to have to close your ticket. Believe it or not, we’ve been out of storage space for the last three months. We have a big order for more storage that we can’t expedite until January, and worse, all the controllers are already at capacity. Purchasing says we can only order twice per year to get the best quantity discounts with our vendors. You are near the top of the list, so we’ll get this scheduled for February.

  Maxine blinks.

  It’s September.

  Phoenix is the most important project in the company. They’ve spent $20 million over three years. And yet, here she is, trying to help, and they won’t spend $5,000 on more disk space. And now she won’t get a Dev environment for five months! She buries her head in her hands and silently screams down at her keyboard.

  Completely defeated, she takes another walk, to nowhere in particular. It’s two thirty p.m. None of the meetings on her calendar seem interesting anymore. It’s just people complaining about waiting. Waiting for something. Waiting for someone. Everyone is just waiting. And she wants no part of it right now.

  She returns to her desk, picks up her jacket and laptop bag, and decides to leave. She doesn’t know where she’ll go, but she just can’t stay here today.

  It isn’t until she’s behind the steering wheel that she decides to drop by her kids’ old school. Not to see her kids—they’re at that age where they don’t want to be seen with their parents anymore. No, she’s going to the lower school where the fifth- and sixth-graders meet for after-school activities. She is proud of having helped the teachers create a coding club three years ago, which has become wildly popular. And she is delighted they’ve found so many students who are having fun with science, technology, engineering, and math before they go into high school.

  Maxine believes learning these skills is incredibly important, because coding is a proficiency that every profession is likely to need in the next decade. It won’t be just for developers anymore.

  She walks into the classroom and immediately sees Maia and Paige, two of her favorite kids to work with. They’re best friends but also fierce competitors, sometimes even archrivals. They’re both smart, ambitious, and have a gift for problem-solving.

  This is the first time this school year that Maxine has visited. She’s surprised at how much older everyone looks and how much their coding skills have progressed. Some are writing what look like games in JavaScript, some are working on web servers, and two students look like they’re writing mobile phone apps.

  She spends the next hour learning what each group is working on, laughing in delight as they show off what they’ve created, and loving it when they ask her questions. When Maia and Paige ask her to help solve a problem, she quickly pulls up a chair.

  They’re trying to complete a classroom exercise to compute the mean, mode, and interquartile ranges of an array of numbers in Python. She immediately sees they’ve made the same indentation mistake over and over again.

  Of course, when they try to run their program, the Python parser vomits at all the indentation errors. They’ve clearly been struggling to figure out what exactly they did wrong, trying everything they can to make the errors go away.

  “May I make a suggestion?” Maxine asks, taking a more active role.

  “Of course, Mrs. Chambers,” Maia says. Maxine sighs, still not sure how she wants to be addressed by teenagers.

  Maxine explains to them how Python indentation works and how it differs from most other programming languages. “But whatever language you’re using, the most important thing is to run your program all the time,” she says. “When I’m doing something for the first time, I run my program every time I change anything, just to make sure it still compiles and runs. That way, I don’t make the same mistake for hours without knowing. Better to catch the mistake the first time you make it, right?”

  She directs them on how to correctly line up some of the indentation. “Let’s see if that fixes the first error …”

  She scans the buttons on their editor. “It looks like you can run your program just by hitting Control-Enter. Ah, looks like there’s one more little change needed. Yep, you’ve now fixed that first error. Now fix up the next error until you’re back into a working state. If you keep checking after each small change, you’ll never have something big you need to fix …”

  Reflecting on what she said, she adds, “One of the really nice things about running your program frequently is that you get to see it running, which is fun, and that’s what programming is all about.”

  The girls smile in understanding and stomp out the rest of their errors in quick succession. Maxine grins seeing them use the keyboard accelerator she showed them.

  The girls are smiling because their program is actually running now. Looking at the output, Maia notices that something seems wrong. Their computed average is way off.

  “Hmm … I think this is an ‘off by one’ error,” Maxine says. “This is one of the most common errors that developers make. It often happens when we are looping through every element in an array, and we miscompute which one is the last element. And that’s what’s happening here—we missed the last element … and believe it or not, when you accidentally process one element too many, that can cause the program to crash or even be exploited by a hacker.”

  Maxine can’t stop smiling. She’s so excited to share this lesson, because over the decades, she’s learned that state mutation and looping is so very, very dangerous and difficult to get right. That crashing ODBC database driver she fixed in the middle of the night a decade ago, which made her so notorious, was caused by this type of problem.

  This is why Maxine is so dedicated to applying functional programming principles everywhere. Learning Clojure, her favorite programming language, was the most difficult thing she had ever done, because it entirely removes the ability to change (or mutate) variables. Without doubt, it’s been the one of her most rewarding learnings, because she’s found that about ninety-five percent of the errors she used to make (like the ones the girls just made) have disappeared entirely.

  Functional programming is truly a better tool to think with.

  “You want to see something cool?” Maxine asks the girls. When they nod, she says, “Here’s what I would do. It looks a little strange, but you can get rid of loops entirely by using iterators—it’s an easier, and much safer, way to write a loop.”

  She scans the Python documentation she finds on the internet, and types one line of code in their editor, hitting Control-Enter a couple of times and converging on the right answer.

  “Voila! Look at this. It does the same thing as what you wrote, but with no loops or conditional logic, such as checking for the end of the array. In fact, it’s only one line of code, with no risk of an ‘off-by-one’ mistake!” she says, actually feeling proud of what she just wrote.

  Maxine is rewarded by “oohs” and “ahs” as the girls’ eyes widen at what Maxine shows them. Maxine is pleased, because even this small exercise has banished some unnecessary complexity from the world. It might save the girls from decades of frustration and make the world a safer place.

  She spends the next hour floating between the teams, having fun watching kids solve problems and teaching them little tricks here and there to make them more productive and joyful. When the kids adjourn, packing up their huge, heavy backpacks, Maxine realizes that she’s in a very good mood.

  The joy of teaching people something that they want to learn is awesome. Plus, these are really great kids. She thinks about how easy everything is here. You hit Control-Enter and the program builds and runs. If there is an error, you fix it, hit a key, and try again.

  In her current work hellhole, it’s the opposite. She still can’t build any part of the Phoenix system. Somehow builds have ceased being a part of everyone’s daily work.

  Maia and Paige made the same indentation mistake for a half hour. At Parts Unlimited, there are a hundred developers probably making bigger mistakes, and it’ll be months before the
y realize they’ve done something wrong.

  Everyone waves goodbye to Maxine, thanking her for all her help. She climbs into her car and slumps in her seat. To her surprise, she feels sad and dispirited—at work, there is none of the joy and learning that she just experienced here. She wonders if this is how everyone on the Phoenix Project feels all the time.

  Maxine is about to start her car when her phone vibrates. It’s a text message from one of her collaborators on an open-source project she wrote to help her with personal task management. She started this project over five years ago to help her keep awesome work diaries. She’s always been a manic record-keeper of how she spends her time.

  Initially, it was just to help her be more productive, to triage her incoming tasks from email, Trello, Slack, Twitter, reading lists, and what seemed like a gazillion other places where work is generated. Her app let’s her easily push work into GitHub, JIRA, Trello, and the many other tools where she interacts with other people and teams.

  Over the years, she’s used this program every day to help her run most of her professional and personal life. It’s where she sends all her tasks. It’s her master inbox, where she can see all her work and move work between all the systems that she works with.

  Many other people use her application too, and some have written adapters to other tools they need to connect to. She’s constantly amazed that thousands of people around the world use it every day, with over twenty active contributors writing code for it.

  She looks at the new pull request from the text message—someone has created a new adapter to the task manager. The proposed change looks fantastic. She’s wanted to do it for years. Their change is quite clever, and she approves of the way the automated tests were written to show that his change works without breaking anything else. He also documented his work, writing several paragraphs on what he did and why. She approves of the way he’s turned it into a tutorial, so others can do something similar.

  She loves seeing other people’s ingenuity and their willingness to make the app better. As the project owner, she sees it as her primary responsibility to ensure that any contributor can be productive.

  A couple years ago, there were over twenty active pull requests, but for a variety of reasons, she couldn’t merge them in—sometimes the changes were conflicting, sometimes her API couldn’t quite accommodate what they needed. She knows it’s dispiriting when you submit a change to someone’s project, but no one ever looks at it or they tell you that it can’t be integrated. If that happens enough, people eventually give up or fork your project and splinter the community.

  So, when this started happening to her project, she spent every evening for weeks rearchitecting her system so that people could quickly, easily, and safely make the changes they wanted. It took a lot of effort, and she personally rewrote every pull request so that the contributors didn’t have to redo their work. But everyone was delighted and grateful when their changes made it in—but not as delighted as Maxine.

  Maxine knows that agility is never free. Over time, without this type of investment, software often becomes more and more difficult to change. There are exceptions, like floating-point math libraries that haven’t changed in forty years—they don’t need to change, because math doesn’t change.

  But in almost every other domain, especially when you have customers, change is a fact of life. A healthy software system is one that you can change at the speed you need, where people can contribute easily, without jumping through hoops. This is how you make a project that’s fun and worthwhile contributing to, and where you often find the most vibrant communities.

  She drives home and is delighted that her husband has already taken care of dinner. She regales her kids about her last-minute decision to visit their old middle school and the exciting new generation of geeks.

  When they disappear to do their homework, she grabs her laptop and brings up the exciting new pull request. She pulls the code in and spins up the new version on her laptop. She logs in and clicks around, testing some of the corner-cases to make sure he got the details right.

  Smiling, she brings up the pull request in her browser and clicks a button, which merges it into the code base. She writes a thank you note to the submitter, complimenting him on his cleverness and initiative.

  Before hitting send, she notices something he wrote: “Maxine, I’d throw you a huge party if you could display a desktop notification whenever someone modifies this property …”

  Good idea, she thinks. She pulls up her code editor, and in the next fifteen minutes takes a stab at implementing this idea. When it works the first time, she grins and laughs out loud, clapping her hands in gleeful selfcongratulation. She’s in a great mood. You can do so much with so little effort because of all these miracles of technology.

  She resumes her note to the submitter:

  Again, really nice work. I’m sure everyone is going to love it as much as I do. Thank you! (And I just added your notification feature. Your offer for throwing me a party is accepted.)

  Hitting send, she wonders if the universe is sending her a message. Her afternoon with the middle schoolers and the ease with which she added functionality to her application (which is years older than the Phoenix Project) shows her what coding should feel like.

  She is able to build things with focus, flow, and joy. She had fast feedback in her work. People were able to do what they wanted without being dependent on scores of other people. This is what great architecture enables.

  She has been exiled to the most strategic initiative of the company, on which the survival of the entire company hinges. And yet, hundreds of engineers are paralyzed, unable to do what needs to be done.

  In that moment, Maxine decides she must bring this level of productivity that she’s helped create for middle-schoolers and her open-source project to the Phoenix Project, even if it means personal suffering in the short term.

  CHAPTER 4

  • Thursday, September 11

  The next morning, Maxine still feels triumphant from yesterday’s numerous victories. But as Kurt predicted, everyone is freaking out. To everyone’s shock and disbelief, the launch was not going to be called off or delayed. Instead, the Phoenix Project is going to be launched tomorrow at five.

  Captain Kirk apparently hit the warp speed button, despite Engineer Scotty telling him the dilithium crystals were about to blow. So, no boring status meetings today. Instead, every meeting is in a genuine shitstorm, with people on the verge of panic. One meeting quickly devolved into bedlam and pandemonium, full of questions, objections, and shocked disbelief. People were furiously typing away on their phones and laptops, and a third of people in the room were making phone calls. It was like watching an old movie from the ’40s, with reporters racing out of the courtroom to the payphones or back to their offices, frantic to break the news first.

  Maxine turns to the person next to her, loudly yelling, “Has Phoenix ever been deployed into production before?!”

  “Nope,” he yells back.

  “Is there a release team yet?” Maxine asks.

  “Nope. Chris, Kirsten, and Bill are mustering up a formal release team today, but I have no idea who’s going to be in charge,” he responds and mimics biting his fingernails in nervousness and fear.

  Maxine looks back at him, speechless.

  Maxine does not delight in the suffering of others, but watching the fireworks surrounding Phoenix is much more exciting than waiting for people to work on her tickets. She groans, realizing that given this crisis no one will be able to work on her tickets now.

  Later that morning, Chris announces that William, the QA director, is in charge of the release team. His goal: get everything into a releasable state and to coordinate with Ops, who were blindsided too.

  Poor bastard. She knows that they are in big trouble. The Phoenix developers can’t even merge their own code together without accidentally leaving parts of it behind or blowing up the build. Pulling off a successful production d
eployment seems wildly optimistic. Or plain bat-shit crazy, she thinks.

  “William, when is your release team meeting?” Maxine asks him as he jogs by. She runs to keep up. “Can I help?”

  “First meeting is in one hour. We need all the help we can get,” he says, not even breaking stride. Maxine is delighted. Finally, a chance to actually use her skills and experience.

  This will be an interesting meeting, she thinks. Maxine has seen how Dev and Ops interact around Phoenix. Instead of acting like an actual team, they act more like sovereign states on the brink of war, with diplomats trying to patch together an uneasy peace, complete with embassies, protocols, and official formalities. Even scheduling a meeting between these two groups requires a summit and lawyers present.

  Regardless, she’s excited to be in the game. In a perverse way, this is the most fun she’s had on the Phoenix Project so far. She realizes she’s grinning from ear to ear. Does this make me a bad person? she wonders. She grins again, not caring.

  Despite trying to arrive early, Maxine is late to the war room. They had to move the meeting twice because the crowd kept outgrowing the space.

  It’s fifteen degrees hotter in the room than in the hallway, and the air is stale. Nearly fifty people are crammed into a space designed for half that number. She sees Chris, Kirsten, William, and a bunch of the lead developers and managers. Kurt, sitting next to William, waves to her.

  On the other side of the table is Bill Palmer, surrounded by a phalanx of faces she doesn’t recognize. She notices that there’s something … different about them.

  The largest one of them to the left of Bill has his arms crossed and a huge, unhappy scowl on his face. He shakes his head in disbelief. “What is wrong with you people? You’re telling me you don’t know how many Windows servers you need, on top of the handful of Linux servers … Tell me again, how many exactly is a ‘handful of servers?’ Is that in metric or imperial handfuls? While we’re at it, you have any Kumquat boxes you need, or perhaps a Tandem?”