(A post in my “Role Models” series…)
In late 2000, I joined a small team tasked with rewriting the core technology at PowerQuest. The old codebase–despite embodying a number of patent-pending concepts, and serving as the foundation for all our revenue–was fragile, rife with technical debt, and unfriendly to localization, new platforms, and other roadmap priorities.

Building our new engine wasn’t exactly rocket science, but we expected our output to be cool and generate lots of thrust. We took our work as seriously as NASA… Photo Credit: Wikimedia Commons
This rewrite had been attempted before–more than once, by some of the brightest engineers I’ve ever worked with. Each time, the press of looming releases, and the lack of obvious progress, culminated in a “we’ll have to come back to this later” decision.
Our little team was confident that This Would Not Happen To Us. We were going to build an engine that was cross-platform from the ground up. No weird dependencies, no assumptions about compiler quirks or endianness, would permeate the code. Internationalization (i18n) and localization (l10n) support would be baked in. Errors would be clearer. Modules would be small, beautiful, and loosely coupled. Gotos would disappear. Vestiges of C dialect would be replaced by best-practice STL, boost, metaprogramming, and other cutting-edge C++ ideas.
Experience Versus Enthusiasm
Before I tell the rest of the story, make a prediction. Do you think we crashed and burned, muddled through, or succeeded wildly?
How you answer will say a lot about you.
If you’re young and optimistic, you may expect me to tell a story with a happy ending. But if you’re an industry veteran, you probably expect I’m going to tell a cautionary tale framed by failure. You know that rewriting a core technology from scratch almost never succeeds, and you can give a dozen excellent reasons why that’s the case.
If you’ve got Roland Whatcott’s genius, you can imagine either outcome — and more importantly, you know how you can choose the future you want.