Six rules for co-development

Building a system together starts with building trust. 

These days, technology is becoming so complex that many systems are built in a partnership of specialized companies. This has the obvious benefit of using the best possible knowledge and experience, but it also has pitfalls. Here are six rules, illustrated by our experiences in a recent project.

In this blog we describe the joint development of an advanced data acquisition system for a fiber optic monitoring system that can detect small vibrations over long cable lengths, using a standard telecommunication fiber. This sensor is being developed by TNO and one of its applications is in assessing a potential location for the Einstein Telescope, which is built to detect gravity waves. 

At the start of the project quite a few aspects of the sensor and the data were still unknown. Thus, the data acquisition and processing system for these sensors was a first-of-its-kind and many aspects of it had to be discovered during the development. 

1. Build trust 

If there is one theme that we have learned over the years, it is that mutual trust and understanding is key. To build this confidence, we typically start with a small project such that the client and VORtech get to know each other without large sums of money being at stake. We call this kind of small projects model scans: a first exploration of the application at hand. 

In this case, we worked out the specifications of the data acquisition system, which helped us understand what our client was doing and where the risks were. This led to some very in-depth discussions in which we got to appreciate each other’s expertise and way of working.  

2. Understand each other’s expertise 

TNO had a pretty good idea about the functionality they needed in terms of data acquisition and processing. After all, they are the experts on this sensor technology. But when they got to the point that a real system had to be built, they readily admitted that it was not their expertise to process such huge volumes of data. Nor did they have experience with setting up data pipelines and CI/CD environments. That is why they contacted VORtech. Still, they understood enough about the software development to understand what we did and what we needed. 

From our side, the engineering background of the VORtech colleagues who were involved made it possible to understand the sensor technology and the kind of data processing that needed to be done. That was essential: without this understanding it would have been hard or even impossible to understand the requirements, and their prototype code.  Still, there were many times we had to ask questions that only TNO could answer. 

3. Short development cycles 

Particularly in the early phase of the project, it was very helpful to have very short iterations. Though there was no formal project management system like scrum, we did work in an agile way, releasing a new version every few weeks. This was important, because the system that we were building was really the first of its kind. New insights led to frequent modifications in the design and implementation. The short cycles guaranteed that not too much effort was wasted on things that needed to change later. It also helped both parties to jointly learn from the experiences. Things one of us would overlook, might be noticed by the other. 

4. Organize the interaction 

Short cycles can only work if there is a well-defined structure of interactions. This is partly about having regular meetings with a clear purpose. Everyone had busy schedules, and it was often difficult to reach each other to align. Having regular meetings made sure that we had enough interaction to avoid costly mistakes. 

Apart from regular meetings, we also put in place the necessary tools. The main one was a shared code repository. This made it easy to discuss topics with the actual code or documents at hand. And we could see each other’s progress, which once more helped to establish mutual trust. 

We also worked together in the same office once every two weeks. This greatly eases interaction as it becomes very easy to quickly resolve any issue.  Also, it builds additional understanding and trust, which is important in co-development as mentioned above. 

5. Have a joint goal 

To get the right kind of energy in the project, it was important that we jointly worked toward the same goal. In this case, the goal was a field test that had to be done at a certain date. Having this point on the horizon helped both sides make pragmatic choices.  

Having a goal as the basis for the collaboration is so much better than just having a contract. If both sides just execute their appointed tasks in the formal contract, then in the end the contract may have been fulfilled legally. However, the result might not have been optimal in terms of the goal.  

6. Get a good arrangement for IP and confidentiality 

One issue that typically looms large in co-development projects is the arrangement of intellectual property or IP.  We have long since decided that it is essential for our business not to claim any IP. We are a service company, and anything we create that is paid for by the client also gets to be owned by the client. 

That is certainly important in this project, as the innovative system involves serious IP. It would not have worked out if the client had had any doubt that they would become the sole and unambiguous owner of the IP. 

Co-development is key 

The project that we describe in this blog is typical for our way of working. We may have deep expertise in software development for compute-intensive applications, but we need the domain expertise of people at the client to build great things together. Therefore, co-development is essential. But it’s also fun because all those involved learn a lot from each other. So, if you see an opportunity for co-development with us, please reach out.