Tennyson is lucky. While most .NET developers are limited to the .NET Framework (and the thousands of available third-party libraries) to solve their software development problems, Tennyson's toolbox touts the Global Services Enterprise Systems Framework. Well, technically, the GSESF is the only library allowed, but then again, it's the only library one should ever need.

"Third-party libraries introduce unnecessary risk into projects," the Global Services Enterprise Systems Lead Architect – or, The Architect, as he preferred to be called – would often say. "If the library is closed sourced, then we will be unable to fix bugs. If it is open-sourced, then we will not only have another codebase to maintain, but it will introduce certain legal risks."

The logic didn't make a whole lot of sense to Tennyson, or any of the other developers, but if there was one thing that management liked, it was doing things that didn't introduce risk. And thus, The Architect's GSESF-only policy became the rule of the land.

One of the nice things about having a proprietary enterprise framework is that there's generally a team that maintains the framework. In Tennyson's case, that team consisted entirely of The Architect, and to his credit, he would always promptly address any bugs or features in the Global Services Enterprise Systems Framework.

"We've been noticing some inconsistent behavior with the Money class," Tennyson explained in a bug report, "the class's Equals() method is overridden, but the == operator is not."

Within a few seconds, The Architect promptly addressed the bug report. He closed it and added a two word comment: "by design."

Tennyson had gotten used to the game, and he reopened the bug report and resubmitted is as a "design change request."

Moments later, the design change request was denied, this time with a longer comment. "The Money class may be used by other applications, which may be relying on the different behavior of == and Equals(). Changing it now would introduce unnecessary risk."

Normally, Tennyson would walk away from any fight once The Architect pulled out the "unnecessary risk" card, but he was sure that no other application was using the Money class, since he was the one who requested it in the first place. Instead of battling over the issue tracking system, he fired off an email.

I didn't want to keep going back-and-forth over issue 
tracking, but the Money class is brand-new in GSESF v10.8, 
so no other group is using it. 

The problem that we're having is that the Money class is 
effectively used as a value type, so developers will 
naturally want to use the == operator to compare it. I'm 
concerned that bugs will slip in here and there overtime.

According to Microsoft's own standards and practices, 
because Money objects are immutable and represent the same
data, they should overload the == operator. In the off 
chance that someone really wanted to test for reference 
equality, they could always use object.ReferenceEquals.

The Architect promptly responded with a single paragraph.

"Standards and Practices" are simply conglomerations of 
tribal knowledge found to be useful in the majority of cases. 
Like school, they are a good base to use as a jumping-off 
point but they often don't live up to the requirements 
outside of their least common denominator domains.

Tennyson decided not to fight it. The Architect did have a point: he was smarter than the industry experts and what they're saying doesn't apply to him. And that's why Tennyson is so lucky: it's not too often you get to work with someone like that.

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