One of the clients for Rudolf‘s company was getting furious with them. The dev team was in constant firefighting mode. No new features ever shipped, because the code-base was too fragile to add new features to without breaking something else. What few tests existed were broken. Anyone put on the project burned out and fled in months, sometimes weeks, and rarely after only a few days.
Rudolf wasn’t too pleased when management parachuted him into the project to save it. But when he pulled the code and started poking around, it looked bad but not unsalvageable. The first thing he noticed is that, when following the instructions in the README, he couldn’t build and run the application. Or maybe he wasn’t following the instructions in the README, because the README was a confusing and incoherent mess, which included snippets from unresolved merges. Rudolf’s first few days on the project were spent just getting it building and running locally, then updating the README. Once that was done, he started in on fixing the broken tests. There was a lot of work to be done, but it was all doable work. Rudolf could lay out a plan of how to get the project back on track and start delivering new features.
It’s about then that Steve, the product owner, called Rudolf in to his office. “What the hell do you think you’re doing?”
Rudolf blinked. “Um… what I was asked to do?”
“Three days and you just commit a README update? A couple of unit tests?”
“Well, it was out of date and meant I couldn’t-“
“Our client is crazy about their business,” Steve said. “Not about READMEs. Not about unit tests. None of that actually helps their business.”
Rudolf bit back a “well, actually,” while Steve ranted.
“Next thing you’re going to tell me is that we should waste time on refactoring, like everybody else did. Time is money, time is new features, and new features are money!”
Suddenly, Rudolf realized that the reason the project had such a high burnout rate had nothing to do with the code itself. And while Rudolf could fix the code, he couldn’t fix Steve. So, he did what everyone else had done: kept his head down and struggled through for a few months, and kept poking his manager to get him onto another project. In the meantime, he made this code slightly better for the next person, despite Steve’s ranting. Rudolf eventually moved on, and Steve told everyone he was the worst developer that had ever touched the project.
The customer continued to be unhappy.
Continuously monitor your servers for configuration changes, and report when there’s configuration drift. Get started with Otter today!
Source: Read MoreÂ
