When working with a new Client, it is not uncommon for us to come across an application that was poorly designed in the first place by an offshore software development team. While this can happen for a variety of reasons, it often means that we have to refactor the application and fix the problems the previous team made, before we can make additional enhancements to it.
Often this is a surprise to the Business Executives, as they thought that they were paying for professionals. Unfortunately, in many cases they were only buying a few Software Developers and not a complete team, and thus did not have all of the roles covered that they needed to have. So, things were missed.
In this Blog Article we will discuss the challenges and several real world examples of what you need to look for.
This is one that still bothers me after decades in the Information Technology industry. It is a best practice to ensure that your code variables make sense and can be followed easily, and if not your code is documented in line.
IF A = B, THEN C
ELSE D + A
What does that even mean? Anyone trying to trace through the application could spend hours trying to figure out what each of these variables mean. Because you don’t know if they are dates, numbers, text, etc. What we want to see are things like this, in pseudo code:
IF (RFQ_QuoteDate < RFQ_RequestedDate) AND (RFQ_Sent = 0), THEN Call (Send RFQ)
ELSE Display RFQ_NotSent to Dashboard
Where an RFQ is a Request for Quote, sure it may take a little more time to write, but a Developer can now read the code.
Many IT professionals don’t like this term, but it is fairly apt. Basically what happens is that you change one portion of the code and like moving spaghetti with a fork, you are now moving everything. Pull one noodle and the whole plate suddenly moves, and this can cause catastrophic consequences.
Unfortunately the longer an application is used, the more Spaghetti Code you end up with. It simply goes back to the 2nd Law of Thermodynamics (Entropy) - the more you build something up, the more complex it becomes and the more difficult to maintain.
There is a natural disagreement between Software Developers and Database Developers. In most cases the Software Developers would probably want to use an Entity Framework which automatically designs the table structure and relationships for them.
Unfortunately, these tools frequently do not take advantage of the database server’s abilities or how each one functions. So, often these frameworks are not optimized for what the database can perform. Which results in slower performance and potential data issues. Plus in many cases it can make it very challenging to troubleshoot any data issues.
No one wants to see a Table Structure like this, but it does happen more frequently than we would like.
So, what do the columns mean? No one has any clue, which is why a Database Developer doesn’t like to use frameworks that automatically create the database structure.
While there should be many other columns in this Request For Quote Detail table, I think you get the idea when looking at the two side by side. One is easily readable, the other is not.
As the CIO of GPG we had made the decision to replace our Indian Offshore Software Development Team with ArkusNexus. Our core application was a custom ERP System that was very complex, as it handled everything from our Call Center to processing Customer Rebate Checks. The code base had some roughly 3.5 million lines of code in it.
When our new ArkusNexus Team took over, we discovered all sorts of issues and problems within the application. The biggest problem was actually self-inflicted, as the original designer of the database, was not qualified as a Database Designer. So, he created all of the transactional tables as if it was a spreadsheet. Where each table was simply a spreadsheet.
There were few relationships between the Table structure, it wasn’t normalized, and in many places within the application you had to export and then re-import the same data. What was even worse, was that when you exported the data it would actually delete the information from the ERP system. So, if someone accidentally deleted the export file, poof - tens of hours of data entry work were gone.
It took us roughly 3 years to fix these problems, as well as migrate the main application to a RackSpace Cloud environment that we could easily scale.
Funny Side Story
Before we were considering moving the Production System to the RackSpace Cloud, we wanted to see what it would cost for us to use AT&T’s Point of Presence fiber ring that was already in our building. So, naturally both I and our Corporate Attorney called AT&T to inquire about doing this.
“I’m sorry, we don’t have any equipment at your building’s location.”
Me: Are you sure, because it says AT&T on it and it is definitely on and working.
“No, we are sure. But we can run a cable from the street to your office.”
Me: I don’t think you would need to do that. I’m standing in our data center and see your backbone fiber optic ring coming into our building.
“Sir, you must be mistaken. We have no equipment there.”
Sam our CEO was hearing this, so he was like Ok, let us shut her down. And I was like that’s fine with me, so I started pulling cards out to disconnect them and pretty soon the entire system was down. And what do you know 15 minutes later an AT&T Senior Engineer shows up at our office wanting to know what happened and he was very worried. Apparently we cut the main fiber optic ring for the entire city of Scottsdale.
Of course, I was like I thought AT&T didn’t have any equipment in our building. He was like yes, we do, we have a major point of presence at this location and I need to see it immediately.
Great, then please ask your Legal Team how much they want to pay for electricity and the property lease in our building for your equipment. Or would they prefer trading these costs for free network access? Apparently, they didn’t like that answer, as a few days later there were AT&T trucks outside our office, rerouting their fiber cable. I’m not sure how much it cost them, but I am sure it wasn’t cheap. Now only if they knew, we could have made a pretty simple deal.
Often one of the main patterns that we encounter is Software Development teams having to cut corners because they were either not given enough resources or time to complete the work as expected. I have seen this happen time and time again. At the same time, as a Client, you have to be careful of the “Bait and Switch”, which some service providers use. As the CIO at Incorporate Massage, unfortunately we had a combination of the two.
Our first Offshore Software Development Partner based in India put forth their best Developers initially, and then over a few months transferred them from the account and replaced them with very junior staff. And you knew that they were being transferred to more profitable accounts.
Now, I am a firm believer that your partners should make a reasonable profit, otherwise there is no reason for them to do business with you. However, if you have a lot of turnover then that really hurts productivity in any role. So, we ended our relationship with our Indian Team and hired ArkusNexus to replace them.
And as I expected, we found all sorts of issues with the code and the database table structure. And this became a year long project for us to fix. The biggest challenge is that we were only given a small team, and we also had to keep the plane flying while we were in the air. With a small team of 5, there is only so much you can do.
Our biggest challenge came from one of our Board Members, who thought our team should accomplish the same goals and objectives that he had done previously with a team of 25. In no universe can you take 25 pounds of effort, soil, or shit and fit it into a 5 pound bag. It just doesn’t work and is unrealistic.
So, if you are going to go the cheap and easy way with offshore software development, expect that the team will have to cut corners to meet your date. Did our team do everything that a 25 person team could do? Of course not, it really is simple math.
In this blog article, we have discussed Several of the Challenges and Concerns in Cleaning up an Outsourcing Mess, as well as giving a couple of Real World Examples. We hope that you have enjoyed this article.
Thank you, David Annis.
