Despite being a very successful product, the core application maintained by N. L.’s company was completely proprietary, and I mean proprietary. It used its own database; you know, kind of like a normal relational database. Its proprietary database had its own proprietary querying language; you know, kind of like SQL. The application had its own scripting language; you know, kind of like VB. Planning ahead to version 2.0’s big new proprietary features, the company was excited to learn about the possibility of creating a parallel universe so that the physics the company operated under, too, could be proprietary.

It was time for a change. The application was maintenance hell – not just because of confusing, undocumented code, but because finding, training, and keeping staff on was near impossible. The company decided that the application would be ported to .NET and SQL Server. The problem, of course, is that it wouldn’t have that home-built feel. No heart. Just another .NET app, built on standard practices and reliable technologies. No, they had to do something to make the application more unique.

Contractors were hired to build database-specific extensions and extended stored procedures in C++. Extended stored procedures allowed their team to have the convenience of linking DLLs with the database calls along with the simplicity and elegance of C++. What better way to intertwine the middle tier with the backend?

They’d also build their own version of code access security. That’s right – they had to use reflection to determine which users had access to which methods in the system. If only the .NET Framework had built-in support for this! Hopefully Microsoft will take note and add it to the next version, perhaps in a namespace called System.Security.CodeAccessPermission.

On top of everything else, all requests were processed by a single method on a web service called ExecCommand():

 

public void ExecCommand(string what, object[] args)

 

N. L.’s role on the project was to make a configurable Thread.Sleep() that could intentionally slow down execution of the ExecCommand method. This feature could not do any logging, nor could it appear in the documentation anywhere. Rule #1 of intentional slowdown: you do not talk about intentional slowdown. Rule #2 of intentional slowdown: you do not talk about intentional slowdown! Why did this feature even exist? Well, database-specific extensions are inherently risky, so they wanted the application to have some room to breathe.

The good news is that the application ran over twice as fast in the next version just by tweaking some sliders. In the following version, the laws of physics employed in their custom universe would further increase speed to process requests before they’re even submitted.

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