Tactical Routes to Keep Production Code Alive and Running

Problem

"I became the CTO of my current company after it had been active for about five years. There was a code base that had been built by a team of four people during these five years, thus giving it a total of 20 years worth of code. Yet, while there had previously been four people on the team there was just one single engineer left who held all the code knowledge. However, a few weeks after I started this engineer decided to quit and leave the company also, and so all of the code base knowledge would be taken with him. The challenge was to find a solution so that I could keep everything alive and running."

Actions taken

I divided my attention into two arenas.

Super tactical route

"In my country we have a notice period when someone wants to quit. The person must stay with the company for 30 days and then after that time they are welcome to leave. I decided to give an incentive to this last engineer and asked him to stay for an additional 30 days. This gave me two months to spend time with him, to learn from him and his experience as much as I could. In parallel, I contracted freelancers to write new code. This assured that we could still maintain items in production and deliver fresh new code for UI without doing anything more significant on the back-end."

Standard tactical route

"I held off production so that our systems wouldn't tear apart. This meant working late nights for a few months. I also began hiring immediately and focused on getting engineers in the door. I gave the new hires peripheral tasks so that they code jump right into the code and start solving issues that were not necessarily production critical. Over the next year and a half I put in motion two phases for rebuilding our production team. First, hiring R&D- we now have eight people; and second, stabilizing R&D- so we are not in danger of risking our production code. Recently I initiated the beginning of phase three- modernizing and clean up. In the past, we were too busy with hiring and stabilizing the situation that now we need to clean up the mess that has accrued over the past year."

Lessons learned

"I believe I made one mistake along the way. We are an analytics company so our business, managers, and team members are numbers people. At one point I thought it would be a good idea to bring an analyst onto the team. Although he was a numbers person he didn't have much engineering experience. I thought he could work his way into becoming an engineer overtime. Well he didn't, and it failed. After six months the person quit and left the job. He was frustrated and felt there was too much pressure on him. I realized it probably wasn't the perfect time to bring in someone more on the junior side. Lesson learned I guess: Don't bring on juniors when you're going through a stressful time."