Leading From Affronts

Scientists frequently need software to support their research, but rarely are strong developers. And why should they be, that software is written to accomplish a goal, and it's the goal which matters to them more than anything about the software itself.

That's where Jared comes in. He worked in a university IT department and his job was simply to write the software the researchers needed. They frequently had a very clear picture of what they needed, along with big piles of math to explain it, plus piles of example input and expected output data.

The team was small- just Jared and two other developers, Larry and Barry. There was no team lead, they could simply coordinate and divide the work. Their manager was nearly invisible, and mostly focused on keeping external office politics from disrupting the work. The work wasn't precisely simple, but it was clear and well defined, the pay was good.

While the code quality wasn't perfect, it was good enough. Since throughput was one of the main drivers of the design, a lot of code segments got hyperoptimized in ways that made the code harder to understand and maintain, but boosted its performance. The software was mostly stateless, the unit test coverage was nearly 100%, and while the UI was the ugliest of ducklings, the software worked and gave the researches what they wanted.

In short, it was the best job Jared had ever had up to that point.

Six months into the job, Jared came into work as he normally did. Larry was an early starter, so he was already at his desk, but instead of typing away, he simply sat at his desk. His hands were in his lap, and Larry simply stared forlornly at his keyboard. Barry had a similar thousand-yard stare aimed at his monitor.

"What's wrong?" Jared asked.

The answer was just a long sigh followed by, "Just... go pull the latest code."

So Jared did. The latest commit eradicated everything. Most of the files in the codebase had been deleted and replaced with a single 7,000 line God Object. And the git blame told him the culprit, someone named "Scott".

"Who the heck is Scott?"

Larry just shook his head and sighed again. Barry chimed in. "He's our technical lead."

"Wait, we got a new technical lead?" Jared asked.

"No, he's always been the tech-lead. Apparently. I had to check the org-chart because I didn't even know- none of us did. But Larry's worked with Scott before."

That revelation caused Larry to sigh again, and shake his head.

"It apparently didn't go well," Barry explained.

A little later that morning, Scott wandered into their team room. "Hey, Josh, you must be the new developer."

"Jared, and I've been here for six months-"

"So, I noticed we'd gotten a little off track," Scott said, ignoring Jared. "I've been bouncing around a lot of different projects, because well, you know, when you're good people want you to do everything, and work miracles, amirite? Anyway, we're going to make some changes to improve code quality and overall design."

So Scott walked them through his new architectural pattern. That 7,000 line God Object was, in part, an event bus. No object was allowed to talk directly to any other object. Instead, it needed to raise an event and let the bus pass the information to the next object. For "performance" each event would spawn a new thread. And since the God Object contained most of the application logic, most events on the bus were sent from, and received by, the God Object.

As a bonus, Scott hadn't written any unit tests. There were more compiler warnings than lines of code- Scott's code averaged 1.3 warnings per line of code. And no, Scott would not allow anyone to revert back to the old code. He was the tech-lead, by god, and he was going to lead them.

Also, 18-person months of work had just been deleted, all the new features that Jared, Larry and Barry had added over the past six months. Their end users were furious that they'd just lost huge pieces of functionality. Also, the multi-threaded "performant" version took hours to do things that used to take seconds. And within a few weeks of Scott's "revisions" the number of bugs tracked in Jira rose by a factor of six.

The researchers did not like this, and simply refused to update to the new application. Scott did not like that, and started trying to force them to change. Their manager didn't like any of this, and pressured the team to fix the new version of the application. And quickly, which meant a lot of unpaid overtime. Once overtime started, Scott "surprisingly" got pulled into another project which needed his attention.

With Scott gone, they were almost able to revert to the old version of the code, but there had been so much work put into the new version that their manager only saw the sunk costs and not the bigger picture. They were committed to sinking the ship, whether they liked it or not.

Bug counts kept rising, it got harder and harder to implement new features, there was a scramble to hire new people and the team of three suddenly became a team of twelve, but nothing could be done for it. The system had become an unmaintainable Codethulhu.

The best job Jared had ever had turned into the worst, all with one commit from Scott. Jared quit and found a new job. Scott kept plugging away, vandalizing codebases in the university for another five years before finally screwing up big enough to get fired. The last Jared saw on LinkedIn, Scott had moved on to another, larger, and more prestigious university, doing the same development work he had been doing.

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.