The Secret Life of Code: A Whimsical Look at Software Changes Over Time

Tales of infamous acts and deep secrets, of dominance and surrender, of praise and shame… all playing out on a stage worthy of Shakespeare but acknowledged by few. It’s a grand story with thousands of characters; but it unfolds on the screens in front of us… actually, we write this story every day.

Gather around… and I’ll tell you an epic tale… it has everything: humble beginnings, increasing prominence, shaming betrayal and surprising recovery… this is the tale of DataAccessUtility.

It started with the creation of a simple code-sharing class: Just a handful of methods to provide access to database connections; there’s no particular claim to greatness here. At the time (10 years ago), most of the surrounding system used an early version of EJBs and there wasn’t much need for direct database connections.

As new systems were created that wouldn’t use EJBs, the new upstart database access class arrived… ConnectionProviderFactory… drumroll, please!

You see… DataAccessUtility (we’ll call it Dau since we’re friends by now) had been hanging out with AppServerDataAccessUtility (Asdau for short). Most of the details have been lost to time, but the short version is that Asdau had been caught with vendor-specific code and had been publicly documented as @deprecated. Dau hadn’t really participated in anything evil, but by association, was also shamed. Word spread, and soon the popular classes didn’t want to use Dau’s connections (everybody said ConnectionProviderFactory was clearly going to win).

Now here’s where the story turns interesting… Dau had not been idle during the years before the shameful Asdau scandal… Dau had been developing access to several different data sources (while the upstart ConnectionProviderFactory still only provided access to one).

Now I know what you are expecting. Usually, someone would come along and steal the multiple data source technology from Dau and give it to ConnectionProviderFactory and that would be the end of the story… and that’s what would have happened… except Dau had a private enumeration of the keys of the data sources. No one wanted to duplicate those… and ConnectionProviderFactory actually didn’t want this “crazy” multiple data source stuff anyway. It’s a classic tale of intrigue, right?

I couldn’t say if Dau’s private enumeration of keys was an intentional power play, or just a quirk of fate, but these few tiny lines of code would be very important in the years ahead. As many important classes increasingly needed access to Dau’s connections, it became openly acknowledged that Dau was essential (in fact, I could tell you stories about the awkward escapades resulting when any impolite class pointed out that Dau still technically carried the @deprecated label of shame).

Now with the Asdau scandal long in the past (most people had forgotten it entirely), Dau and ConnectionProviderFactory figured out a useful solution to the issue: they agreed to share access so that both classes could distribute connections from each other. This was beneficial for everyone, though most people expected that ConnectionProviderFactory would rapidly be the preferred data source class.

Remember how I said Dau was still carrying the @deprecated tag? It turns out that Dau was actually the more friendly of the two classes, and now with ConnectionProviderFactory not really being the owner of the increasingly important data source enumeration… well, I can’t say I’m proud of how the system behaved during this time… but one by one, each of ConnectionProviderFactory’s methods were shifted over to Dau. Just a year or two after the initial sharing agreement, the open secret that Dau didn’t deserve the @deprecated tag finally received justice and it was removed.

Frankly, I’ll admit, it was quite a celebration! I remember I jumped up from my desk when I heard the news! This poor class had labored for years under this no longer appropriate shame. Dau had been quietly working to provide increasingly advanced support for data access in many different contexts (batch processing systems, app servers and even special “sandbox” sources for unit tests)… everyone could rely on Dau for trustworthy support anytime.

Many surrounding technologies had been changing throughout this tale, and Dau is no longer a simple code-sharing class. In fact, despite humble beginnings (and some poor treatment), against all odds, now almost every feature throughout our system indirectly uses the data sources and context information that Dau provides.

I don’t know about you, but I think it’s an inspiring tale… what epic stories have you seen play out in code?