After his chilling encounter in the company’s IT Cave, new hire George spent some time getting his development workstation set up. Sadly, his earlier hope that the PC in his office was a short-term placeholder until something better comes in was dashed to pieces. This PC was a small-form-factor budget system, relying on an old dual-core processor, 2 GB RAM, a 5400 RPM “green” disk drive, and integrated graphics with a single output port, to which was connected an aging 17" LCD monitor with a failing backlight.

A preview of a glitchy font

George got to work installing software packages from a network drive, presumably clicking itself to death in the dark IT office. With a PC nearly ten years behind the curve, George had plenty of time, several days, in fact, to drink coffee while exploring the building. His unease from the encounter with the IT guy eventually faded as he met other employees who seemed as normal as he, discovering conference rooms with normal-looking Scrum boards, and offices and cubicles that would not appear out-of-place in any modern, successful software company. A friendly member of the Marketing Department even gave him some swag: logo’d pens and stress balls and notepads. Perhaps the unusual IT guy and his dark, precarious office was just an anomaly to an otherwise excellent organization.

A week into his new job, George finally had his system set up enough to look around at the software products he’d be working on. During his interview, he’d been told everything was “superbly” documented.

A coworker emailed him links to their developer documentation which was hosted on an internal server somewhere. George followed the link, and his web browser sat on a loading page for way too long. As he waited, and waited, and waited for the page to load, he almost thought he could hear the clicking and clunking of failing disk drives from whichever ancient pile of failing hardware served as the company’s documentation server, but eventually a SharePoint page presented itself on his screen.

The “Developer Documentation” was unexpectedly short. In fact, George read through it faster than it took to load, feeling a sense of dread once he realized what it actually was: three pages of buzzword-laden marketing material! He read about how “superb” the application is and how it has helped millions of companies “leverage new synergies for key wins”. Nowhere could he find a simple, developer-centric description of the application. When he pressed for more documentation, his coworkers shrugged. “That is the documentation,” they explained. “The bosses say it’s good enough and it’s a waste of time to write more.”

George’s sense of dread continued to increase.

And so he did all he could. He checked out the application from source control and went spelunking.

On his first run, he noticed the application’s text did not look right. Characters were glitched in various ways, with bad kerning, inconsistent alignment, and missing/extra pixels, though it was still generally readable with some effort.

Thinking he was missing a dependency, he asked his coworkers for their opinion. “No, it normally does that,” they explained with a shrug. “Most of the time.”

“Do we have unit tests for this?” he asked, but deep down in his gut he knew he wouldn’t like the answer.

“Testing programs are in the design and planning stage,” they responded, even though the application had been on the market for eight years now. “The bosses don’t like to spend too much time on testing.”

He still had no direction on what tasks to perform, so George took it upon himself to dig into the font issue, if nothing else to learn more about the codebase. He downloaded a few third-party font test programs from some prominent tech companies and they all agreed that the application had nearly 1,300 basic font rendering errors.

His sense of dread was starting to overwhelm him as he considered his future. How could an application possibly have millions of sales and installs with nearly-unreadable fonts? And how could it possibly be maintained with no testing and no documentation?

He wrote a memo explaining some of his findings and forwarded it to several coworkers, and asking various questions about it before putting too much effort into fixes that could cause issues unforseeable by a newbie who was not familiar with the history behind the application’s overly-complex font-handling codebase.

Later that day, he received a long email directly from the company president. In tirade form, it explained that George was wasting time, there can’t possibly be that many bugs, and if anything like this happens again the time would be deducted from his paycheck. It ended with the president explaining that George was obviously a f***up who would never amount to anything at the company, but he was willing to give him another chance.

George didn’t want another chance. As he walked past the IT Office on his way to the HR Office to announce his resignation, he briefly wondered how much damage his foam stress ball could do to already-failing disk drives if he were to chuck it through the door into the darkness within.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!