28 December 2016

In a previous blog post I related a coding standards horror story from early in my career. A couple commenters asked for part 2 of the story, mostly to see how my boss, Mark, dealt with the chaos we found in the company who acquired us.

There are two things I think are fortunate that relate to the story.

First, they bought our company because they wanted our software and because they wanted Mark. It is quite possible that nobody in the world understood the vertical industry and had the software dev chops that Mark provided, so he had a lot of personal value.

Second, before the acquisition I’d been tasked with writing tooling to enable globalization support for our software. Keep in mind that this was VT terminal style software, and all the human readable text shown anywhere on the screen came from text literals or strings generated by our code. The concept of a resx file like we have in Windows didn’t (to our knowledge) exist, and certainly wasn’t used in our code. Coming right out of university, the concept of lexical parsing and building compilers was fresh in my mind, so my solution was to write a relatively simplistic parser that found all the text in the code and externalized it into what today we’d call a resource file.

That project was one of the most fun things I’ve probably ever done. And one of the few times in my career where a university compiler design course directly applied to anything in the real world.

Because Mark was so well regarded by the new company, he ended up in charge of the entire new development team. As such, he had the authority to impose his coding standards on the whole group, including the team of chaos-embracing developers. Not that they were happy, but this was the late 1980s and jobs weren’t plentiful, and my recollection is that they grumbled about it, and the fact that it was a “damn Yankee” imposing his will on the righteous people of The South. But they went along with the change.

However, that still left massive amounts of pre-existing code that was essentially unreadable and unmaintainable. To resolve that, Mark took my parser as a base and wrote tools (I don’t remember if it was one tool, or one per coding “style”) that automatically reformatted all that existing code into Mark’s style. That was followed by a ton of manual work to fix edge cases and retest the code to make sure it worked. In total I think this process took around 2 months, certainly not longer.

I wasn’t directly involved in any of that fix-up process, as I had been assigned to do the biggest project yet in my young career: building support for an entire new product line in a related vertical to the focus of our original software. Talk about a rush for someone just a year out of university!