In the late 90's, Roman worked for a major speech processing software development firm. His project group was doing fine. In fact, they were doing better than fine: they finished up their project several weeks before the deadline.
While most project teams would drag the project out with additional "testing" or "quality assurance" or "long days spent staring at their screens doing nothing" (I'm sure there's a more business-friendly way of putting that), Roman's team split up and helped some of the other, not-so-fine teams. Roman joined the Core Group.
The Core Group was 300 developers strong and had already managed to go 100% over budget and 130% past its deadline. An impressive feat considering the former was measured in "millions of dollars" and the latter was measured in "quarter years."
It didn't take too long for Roman to figure out why they were so behind. When the project started, one of the main design goals was to make the product platform independent. They also decided to use C++/MFC. While some might see "platform independence" and "vendor-specific library" and say "impossible," the Lead Architect had a much more optimistic perspective: they would create The Wrapper.
The Wrapper's goal was to wrap 100% of the functionality that MFC provided and add a bit more. MFC classes like CString were wrapped inside of Wrap_CString and given an additional thirty-one constructors. Granted, only two of those constructors were ever used, but one never knows: somewhere someone down the line may just want to create a Wrap_CString out of six individual char variables. It could happen.
The ultimate fun for Roman came when he encountered the class wrapping MFC's Windows registry access. It was one of rare the pieces of The Wrapper code which actually featured a comment. Though only a single line, it spoke a lot for the entire system ...
// This might be difficult to port to another platform