Having been in the IT industry in various capacities for the past 18 years, I have learned a thing or two about the perils of supporting systems adhering to certain conditions. In specific, systems that have a small support budget.
The story goes like this (and I am sure this will be well known to you if you are not still wet behind the ears): A new project gets allocated a certain budget - could be big or small. A team of contractors get assigned to implement the system. Once implemented and tested, the contractors - as good contractors always do - go on to new projects. This is not unlike the civil engineering industry, where a bridge would be built and the contractors move on to the next project. In principal there is nothing wrong with this, but it creates a HUGE dilemma. In the case of civil engineers building a bridge, when the contractors leave they do not take any special knowledge with them. The blueprint of the bridge, the materials used, procedures used etc. are all documented and certified and approved throughout all stages of the project. This is why it is called engineering. Engineering is the use of scientific principals guided by rigorous processes and methodologies to ensure compliant, safe, reliable systems are built. Therefore the maintenance crew understands the system and can maintain it.
And in that lies the difference between the engineering world and the IT industry. I am an Electrical Engineer. Yet I have spent all my professional life in IT. I have all the background training to understand an engineer's mindset, and have all the practical experience to understand the IT landscape. And let me tell you, IT is like a children's party when compared to engineering. I have respect for engineers, I have none for IT people. And this is not necessarily due to the people in IT, but more due to the industry as a whole. People call themselves Software Engineers, yet they have no clue what an engineer is. IT does not follow processes, they follow deadlines and tight budgets. Why do you think each and every application has regular software updates? But bridges don't? That is a rant for another day though.
Jumping to the start of this essay, the problem with supporting IT systems is that the same amount of knowledge is used in an IT project, yet this knowledge walks out of the door when the contractors leave. And trust me, they will leave. Very few people are as dumb as I am and stay with their customers/projects and support it for a decade. I say dumb because it holds you back, your ability for growth. It is of course great for the customer. The difference between an IT project and an engineering project is that of time. Engineering has been around for almost a millennium. IT only for about 60 years. Engineering has established protocols, documentation, processes and policies for creating systems in a sustainable and maintainable manner. Nobody worries that a bridge that was just completed is safe to use. People will gladly drive across said bridge at the opening day - trusting the processes behind the engineering. People are not scared that there is a bug in the system, that the bridge will collapse underneath them. They trust it so much they risk their lives blindly, daily. And IF that bridge do break, the engineer loses his license, possibly facing criminal prosecution and it is the end of his career. The same does not hold for IT systems. If there is a bug nobody is held responsible or accountable. People actually EXPECT a new system to have bugs, to the point of being unusable. That is why most major corporations refuse to deploy a point zero release on their networks, they wait for the first service pack to iron out the inevitable first round of major issues.
But that raises the question - how often does civil engineering (or any other engineering discipline) create "bugs"? The answer is much, much more rarely than software / IT systems. I do believe the reason is chiefly due to the processes behind the two industries. In addition to that, engineering's artifacts by definition allows for the contractors to leave the job without any concern that they would take valuable knowledge with them and subsequently putting the system they built at risk. Any professional maintenance company can easily support these projects as the handover process is well defined, as well as the processes to create the system.
And therein lies the problem with IT systems. If the primary contractors leave, regardless of the documentation they leave behind, for anything but a trivial system my experience tells me that it is very hard to find a competent person to actually support that system. I must admit, this is where engineering and IT differ. Once a bridge is built nobody fiddles with the engineering aspect of it, unless there are huge problems. Bridges are not enhanced every couple of months. Once built they pretty much stay like that - it is a static system. IT systems change continuously. Bridges are built using only a couple of well defined methodologies. IT systems can be built using a vastly complex combination of programming languages and components. So the maintenance contractors need to understand the system as well as the prime contractors to support / extend / enhance the system. But the handover process seems extremely hard.
The handover needs to include:
In my experience, it seems incredibly hard to transfer these skills. It takes about 6 - 12 months to get someone up to speed maintaining a system if they are skilled, assuming the system consists of about 130k LoC. That is a VERY rough estimate. The problem? Those contractors leave for other more lucrative projects after 6 - 12 months. What happened to all the skills transferred? It is lost. And if the prime contractors are not involved at all? The system owner has a huge problem. They will have a system that is next to impossible to extend / support in the case of problems.
I guess this is not entirely true. There are skilled contractors out there that will be able to understand the system in 3 months, but the problem is they rarely if ever waste their time on supporting existing systems. People that skilled work on new projects. That is where the stimulation is. There is a huge demand for really skilled IT professionals, they will not be looking for maintenance jobs. So you are left with young, junior developers. And in my experience none of them have the capacity to support mid sized systems. The time to train them exceeds the time frames acceptable to the business. And no prime contractor will spend years training a junior. They will want to move on to new projects.
So how do you fix this? I believe you need to employ a developer to support your custom built system. Depending on the size it might be a team of developers. When you employ them, you can manage their time, salary and bonuses. You can keep them motivated. The problem is that many companies reach out to large IT service providers. Why is that a problem? Because the IT service provider does not support the system, people employed by the IT support provider does. And those people are like all people, they leave. You have NO control over the employees that work on your project. Only if you have insane budgets you can afford requesting say three people be dedicated to your project, but this usually busts most budgets. So even though you have this large IT service provider looking after your system, the skills for maintaining your system still lies with the individual employee assigned to your account. And trust me, any IT service provider will follow a typical business model of balancing their fee against the cost of resources assigned to your account. It is just good business to try and make a profit. Since a good software developer can easily earn between $70k and $120k per annum, you will need to spend a LOT of money to support your system with a redundant team of developers.
This brings me back to employing a developer or two. Those developers can still leave, but you have much more control over incentives to keep them. Until the IT profession reaches a point where we have a more seamless handover process and a proper engineering discipline for building software systems, we are stuck with this dilemma. And because of this I am still supporting systems I have built in 2003. I am not complaining, even though a change of scenery would be really welcome, I feel I have an obligation to support my clients while they struggle to find alternative support providers that are reliable and can get the job done as well as I can. As for me, that has not yet happened in the past 10 years.