Reduce user acceptance testing time by 60%, save a few millions
Story time
Once upon a time, in a country far far away, there was a giant underwater robot being build. When I say, giant, I mean the robot was slightly bigger than a double decker bus.1 It’s aim was to act as an emergency pipe repair. In case an underwater pipe started leaking gas or oil, it could be deployed quickly to clamp it and reduce the ecological impact of the leak. Then, planning could occur to properly fix it.
I was in charge of writing all the command and control software for the robot. As a note, I will be using the royal we from now on. Yes, there were others involved, I was not a lone wolf!
The problem(s)
The main difficulty was that the robot was being built at the same time as the software was being written. There was no way we could do hourly, or daily, or even weekly releases. Also, the robot in question lived in a warehouse in the far away country and most certainly did not have an internet connection. If you move a 400 bar hydraulic motor, you want to make sure there is no human in the way because the hydraulic is not going to notice crunching someone. Thus, no internet!
What we did have were electrical drawings showing which sensor was connected to which input and outputs. But, we knew that these things change. One of the classic example is leg up/down controls. Whatever the drawing says will have to pass mechanical contrains. Doing it the drawing way involves cables crossing and that means that the casing no longer locks so water can get in. So, they get swapped. The technical drawing should be updated, but …
I decided to do three things:
- Write a hard simulator with a world model. If an input meant the leg was going up, then the simulator would change the world model to reflect that and its impact would be felt in other aspects of the model.
- Write TDD tests first for everything. Some of them were, by nature, not true unit tests since they had incestuous knowledge of the internal of the code. But, as the Way of Testivus states, better a bad test today than a perfect one tomorrow.
- Write BDD stories for the each feature. The goal was to make sure that the most common operations were taken care of and were well defined.
It did take longer to write the software. But, was it worth it?…
The result
We went to the far away country and worked 12 hours shifts for two weeks, including weekends. This involved dozens of people: hardware engineering, mechanical engineering, electrical engineering, and a few drivers as well as a crane to drop the robot in the water. Thankfully, there was no boat and no trip in the middle of the sea.
The above image is one of the cabins where we ran the software from. The red / orange suites were very fetching. After all, we needed to be seen in the warehouse.
By Wednesday of the first week, it was clear we would not be needed in week two. By Friday, we were on our way home.
60% time saved.
Nice.
What does this mean? It means, operation costs saved, time saved so the people can focus on different projects, and an assurance of quality. Probably several millions euro saved right there.
Conclusion
Two side effects happened as a result of this. First, my company got a lovely letter from the project leadership saying it was the smoothest, best quality software they had ever got from us. This was timely since our contract was being renewed.
Second, several years after I left the company, a developer there reached out to me. They wanted to personally thank me for the work I did on the simulator. It was still being used to save time and test code years later. The initial layout of resources to code the simulator paid for itself in more than one project, over ten years2.
I have done this before and I can do it again for your company.
Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.
How about getting in touch to see how we can help you?