In the world of software consulting, there are many ways in which software is delivered to the client. Sometimes, a consulting company may choose to sell the software to the client, providing both the working application and the source since (most of the time) the software is so customized to the client’s need, the consulting company does not have much reason for keeping the source code to themselves.  In other situations, though, consulting companies may choose to license the software to the client, with regular patches and bug fixes, while retaining all ownership.

Paul was working as a freelance coder, fresh out of college, when he accidentally stumbled upon a third option: give the source code to the client, but obfuscate the software to such a degree that any developer who tried to work on it would go mad.

While Paul’s background was in software development, he had been working in QA until his freelance business started picking up.  He had printed business cards and passed them out to anyone who seemed interested, but overall, business was pretty much dead.  That is, until one November morning, when Stuart, the operator of a local clothing manufacturer, called him.

“Hi. May I speak with Paul, please?” Stuart said.

“This is Paul.  If this is a telemarketer…,” Paul replied.

“No, no,” Stuart assured him.  “My name is Stuart, and we need a freelance software developer ASAP.  A mutual friend of ours gave me your business card.”

After some discussion, Paul discovered that Stuart had been the ‘victim’ of a consulting company run by Richard.

Richard’s business was run on the philosophy, “Once you buy from us, you’re stuck with us,” and in that regard the consulting company was extremely successful.  They would sell the software to clients only to hear from them months and years later - any time a small update was required.  In cases where Richard’s team had noticed some other developer had modified their work, they would double the rate as a form of punishment, claiming that they needed to fix what the other developer had done.

Richard’s team were experts at making code complicated to read.  Not only were they required to have their applications utilize multiple database instances within a single DBMS, such as SQL Server, but that additional DBMS software, such as MySQL, had to be loaded on the same server and used by the application.  Furthermore, the applications often utilized multiple versions of SQL Server - for example, 2000 and 2005 - on the same server.  Richard’s team managed to mix IIS and Apache web servers for some web applications and JSPs/ASPs for others.  For desktop applications, they would often have a .NET application drop to command line to load a Java class or PHP script.  Shockingly, they did deliver functional applications most of the time.  Obviously, commenting any line of code was against company protocol and would be met with severe punishment.

Stuart had bought an inventory database system from Richard’s company, and now wanted Paul to update it. The change he wanted was simple enough:  they needed to add and remove certain types of clothing like jackets and belts from their inventory, but the system that Richard had designed had no way to modify the list of options.  Stuart also explained at length how the system was known to be complicated and many other developers had been unable to assist.

“I know it’s a long shot, but is there any chance you can help us?  We’ll give you whatever access or resources you need,” Stuart pleaded.  “We just need to have some new clothing codes added and a few old ones removed.  New staff keep getting confused when they can’t find the new codes and it’s wasting a lot of time when they pick one they think is the closest.  We’ve had several stores receive completely incorrect bundles of clothing!”

Paul was brave and agreed to take a look, but told Stuart, “I will give you my honest evaluation, but if it is too horrible a train wreck of an application, I won’t touch it out of fear of breaking it.”  With a badly mangled screen shot that had been pasted into a Word document in hand, Paul set out to understand the application.

Navigating passed the piles of database instances and the ASP / Tomcat cross-configuration, Paul arrived at an .aspx file that appeared to be the central point for communication for Richard’s application inventory system.  It seemed that most of the data was being pulled from a SQL Server instance, and it was a good hunch that database would contain the guts of the application.  Paul connected to the database instance and instantly became sick.  The database had eight tables, with names ranging from as “A” to “StoreFromIDRefererHolder,” and everything in between.  In fact, six of the tables only contained two columns, the first the ID, and the second a value.  The original author had simply added another table any time he needed to add another property to the inventory system.

Out of morbid curiosity, Paul ventured further into the .aspx to see how the system processed the database information only to discover the line:

SELECT * FROM *

This line was followed by an endless series if statements.  The design, if one can call it that, was to query the entire database on every request and then use the if statements to parse out the response.  Not sure he properly understood this, Paul tried a number of operations on a test database only to discover it took 5 minutes to process some of his requests.

Richard’s system was crazy but stable, and Paul for the life of him could not imagine the design meetings that led to this application.  At that moment, Paul decided to avoid thinking about it, added a few entries to the “StoreFromIDRefererHolder” table and closed his connection to the database.  Paul called Stuart the next morning to let him know the results.

“You should be good to go, I added the missing codes, but I’m reluctant to remove any existing ones as I’m pretty sure this will break the application,” Paul informed the client.

“Look Paul, you’re a life saver.  This is great!  I thought nobody would be able to deal with it.  How much do we owe you?” Stuart responded.

“It didn’t take that long, just $250,” Paul replied.

Paul could hear Stuart laugh over the phone.  “Something funny?” he asked.

“Yeah, Richard’s team had a different approach.”

“Oh? What were they asking?” Paul inquired.

“They were throwing around figures in the $10,000 range, just to look at it,” said Stuart, with a note of distaste in his voice.  “And at least $40,000 to supply an update.  Anyway, your invoice will be paid tomorrow, and we'll be keeping your number on file for sure.  Thanks again!”

Paul was happy to receive the check a few days later and took one important lesson away as he started on his path to becoming a professional software consultant:  Sometimes, bad software can be profitable.

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