It’s uncanny to observe that in every new engagement I get onto, we always encounter a Software Ownership Transfer situation. The latest instance was at a Government Organisation. We had to work with the existing vendor who provides maintenance services. We had to take over the product from them. All of the work had to occur out of the Government premises.  At the same time we also had to undertake a technology transfer from another of the Government’s super sensitive lab which also had been doing research on securing the product.

In effect we had to take over the code base from the existing maintenance vendor and in parallel we had to take ownership of the technology experiments run by the Government Lab as well. And as in most project situations, we were severely understaffed when we began. We hardly had three developers and it was quite overwhelming to take over from two entirely different organisations.

And as it turned out we had two extreme experiences on both transfers.

The team in this Lab had done thorough groundwork to prepare for the Technology Transfer. They gave us a slide walk-through on the first day. From the next day onwards they had planned for dedicated training for our developers. The downside? Well this Lab functioned in another part of the town. Our team had to dedicate the entire day if they had to go to this part of the town. On top of that, given the sensitive nature of the work this lab does, our teams were barred from taking our laptops and even phones. All learning could be captured only on physical paper. When it came time to transfer the actual software, this Lab needed specific email requests to be sent to their department from our client Government Organisation. There were heavy interactions required in order to get the actual software. Multiple approvals were required for the software to change hands. And once the software arrived, we found it did not work in the machines that we were provided with. It took quite a bit of back and forth before we could solve issues and get to a working software. That being said, everyone on all sides were very co-operative, but the system got in the way.

This side of the transfer took a significantly higher effort. To start with the vendor teams were uninterested to spend time with our team. The vendor team’s management it seemed had instructed them to spend time with our team only with their express permission. In effect, for every meeting the vendor team members needed to get their leadership’s approval. And the leadership was not sitting in the same town. We found the going difficult initially. Our client (The Govt department) did a lot in order to push the vendor to work in a more co-operative fashion. Having said that, several members from the vendor organisation were also very helpful throughout our interactions. We spent a lot of time in trying to understand the core features of the product.

Our team was quite excited to take the technology transfer from the Government Lab. That work was ‘cool’ and interesting. On the other hand, our team did not particularly like taking over the work done by the maintenance vendor. It was running on a 10 year old legacy code base and the technology had not kept pace with time. However the vendor system was critical because that was the production system. We had to understand how things run in production as well as understand real-world issues before jumping on to what one may consider a more ‘esoteric’ solution.

This tenuous situation from our team combined with the recalcitrance from the maintenance vendor kept us in a state of uneasy dead-lock for a long time. We built solutions in the periphery of the core system while not taking complete ownership of the system.

The above situation continued for about 7 months as both our teams kept working our way. We built solutions that enabled the core product. We put in CI/CD set-ups but our team was careful to not pick up any work on the core product itself. We had to use the test environments of the maintenance vendor. That often did not work out so well, as there were conflicting priorities for the environments. We also had to use the release processes established during the vendor’s tenure. Some of the processes had heavy overheads given it was set-up for a non-Agile paradigm. I tried to nudge the team continuously to pick up more ownership on the core features. It was getting very evident that one party will have to take full ownership. The client organisation also wanted us to take it on.

Through some of the initial releases, our QA team paired with the other vendor informally. Slowly our QAs got the confidence to test the entire system. I suggested that going forward, we can handle testing of releases. The client agreed to it. Our QA members were also open to take on the responsibility.

Our team was using Git as it enabled distributed development. The maintenance vendor had inherited SVN and continued to use the same. We had initially faced some headwinds when picking up Git, but were able to sail through with the choice. However, we reached a point where both our teams were making changes to the code base. One set of changes were occurring in Git and another occurring in SVN. There were many layers to this conversation as SVN was the source code repository by  policy. Changing a policy document within a Government Organisation is very difficult. But the Government authorities were ready to have us use Git so long as we took full ownership of the product. In the meanwhile we came up with training documents on Git and offered to train the vendor employees on Git as well. However the actual training never took place as a clear mandate never came through.

We were even able to make a couple of releases in the above set-up. However, the break-point came soon enough. The above conversations continued in the background until there came a point where we were ready to make  a particular release. At the same time the other vendor had also fixed some defects. We had insisted they make the changes into Git. The vendor neither agreed nor denied. However their Bug fixes were a higher priority on the field as a number of problems were occurring on the ground. At the end of the stand-off we had to take in the changes from SVN of the vendor and add it to our release. The team had to work over the weekend as the client leadership insisted that no one leaves office until the release is made. The SVN versus Git issue was surfaced at the highest levels. It became quite apparent that we had to take ownership for the entire code. The team also was more open to the idea given the frustrations they went over in merging code from SVN to Git and having to address issues that arose from the fixes the maintenance vendor had made. After about 7 months, our team felt that they could make functional changes as well if not better than the incumbent. Of course the decision was facilitated by the extra hours and frustration the team had to put in for that particular release.

It goes on to show that Ownership Transfer  continues to be a bane in our Industry. Our team eventually took over ownership only when we realised that not taking ownership is going to be more difficult than taking ownership. This despite the fact that we had several conversations with our teams formally and informally over several months. And this despite the fact that I shared my experience on the topic with the team and stakeholders several times 🙂