I received a call this morning from a company that I've worked with previously, having assisted them with a custom eConnect integration and with Post Master Enterprise for automating their batch posting. The caller introduced himself and explained that the company's GP developer, with whom I've worked in the past, was in the hospital with a serious issue, and he may not live.
The company has been using Dynamics GP since at least version 8.0, and they have over 300 active Dynamics GP companies. The company has developed several custom integrations over the past 5 years to automate several system integrations. Things are still working, but now that the GP developer isn't around, they are finding some integrations that aren't occurring. And they don't know where to start looking.
They are now attempting to reconstruct the business processes, integrations, data sources, and many other things that the developer managed. They generally know what he was responsible for, but nobody else in the company has any knowledge of the specifics. They don't know where source data files come from, whether they are transformed prior to import, where they are saved, or what integration processes them. Most of the integrations are automatic, but they are finding a few that appear to involve some manual processing.
I spent about two hours working with the customer, scouring logs and files on their terminal server, to identify some information about the integrations, identify some source code, and get some understanding about how things work. During the call, I didn't see any signs of source code control or documentation.
While we learned some things about some integrations, they were looking to process a specific type of monthly AP invoice, and unfortunately, we were unable to find anything that appeared to be related to that monthly import into 200 company databases.
They are still trying to get the developer's laptop and see if they can access the files on it in the hope that it may have some clues as to how the monthly AP invoices are processed.
It's an unfortunate situation in many regards. A typical response might be "Why doesn't anyone else know what he was working on?". Yes, in an ideal world, you would have a backup employee for every task who can step in and take over another role. But if you are a GP consultant, you've probably seen dozens of companies in the SMB space where most employees exclusively handle certain tasks. Most mid-market companies don't have the resources to have two employees doing every task--even critical ones.
While IT is sometimes general enough that a system administrator might be able to pick up some SQL or GP related tasks, it isn't common for an average GP customer to know the details of custom code, and I speculate that it's even less common for a GP customer to have more than one GP developer on staff. The customers and partners I work with might know that Steve Endow is the guy to call for a particular integration, but other than the documentation I provide with all of my work, they wouldn't know much about the details of the work that I've done and all of the context related to some of the projects.
I think there are many lessons to this story. Off the top of my head, a few come to mind.
1. Centralized source code control should be used without exception
2. Documentation is important, even though nobody likes creating it, maintaining it, or reading it
3. Being organized is very important if you expect to cope with the loss of a key employee
4. It is prudent to maintain a "Hit by a bus" plan
Source code control is probably the easiest practice to maintain. Visual Studio has excellent integrations with Team Foundation Server, Git, and SVN, so other than the initial learning curve of each of those source code control tools, it's just an extra button click in Visual Studio. There just isn't an excuse for a developer to not use some type of source control and ensure that someone else can access the repositories in an emergency.
Documentation is disappointingly rare, particularly for internal IT projects or where employees are doing custom development. And even if something is documented, the documentation usually doesn't cover all of the hundreds of details that someone might need if the main developer is gone.
Being organized can be a challenge. Some people are organized and have good habits to keep things organized, while others aren't. Some people are organized in certain areas, but not in others. And some projects start out organized, but after 5 years of development, the scope of a solution can grow to a point where code can become very difficult to understand if it wasn't refactored or reorganized over time.
And then there is what I call my "Hit by a bus" plan. If I'm hit by a bus, what information would be required to minimize the disruption to my family, my colleagues, and my customers? Perhaps a nicer name might be an "Extended vacation plan".
I provide documentation with every project I develop, and all of my source code is hosted online. I provide partners with access to their code repositories so that if I disappear, another developer can step in and update the code if necessary. Even with all of this in place, I'm sure there are still hundreds of missing details and unanswered questions, but all of the critical information is available to move forward.
It's not something that we typically think about or even want to think about, but I think it's a prudent part of business continuity that any company needs to work on.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
No comments:
Post a Comment