Solving complex problems in software development – part 3/6 – … turns to a Walk in the Dark

First time the ATO drove the subway train at a test track on site, the train stopped 10 meters after the stop point. If the ATO ever stopped within the limits around the stop point this first day of testing, it was a slow jerky ride, not anywhere close to nice. This first day of testing for the team was not fun. It was embarrassing. Reality had now come into the team’s life and told them that their picture about reality was far too narrow.

Let us stop again and put the real situation into the Cynefin™ framework. Then it should look something like this.


The team has finally realised that they are not in the Obvious domain, they are in the Chaotic domain. And in the Chaotic domain we need to take control again as fast as possible. But, the first thing after we take control, is that we still try to keep the old, we do not want to change. So, instead of really leaving the Chaotic domain, we first end up in the liminal state between the Chaotic and the Complex domain. It is the edge of chaos, and here the novelty can not emerge. It looks like this.


And this is exactly what happens with our team, because they think that maybe we can calibrate all available parameters, until the software works.

So, the engineer and his team start to adjust the regulator (PID), but they are not even close to find the solution, no parameter choice is even close to acceptable. Not regarding the jerk, not regarding the precision in the stop, and always very hard braking just before the stop point, where the braking should be softer. The stops are so hard, that the train almost swinging back and forth some seconds after the stop. The same thing that happens when you do not release the car brakes, just before the stop. Fortunately, the team has good logging equipment, so it is possible to see a lot of parameters, about the input to the ATO, like speed, ATOs reaction and its output.

After some more testing, a finding is that the D-part (Derivative) cannot be used, due to that the speed, even though it is time stamped, is not accurate enough even after calibration due to time elapsed. So, our team changes to a PI-regulator, with a strong P-part instead. After some days of testing, they find a PI parameter setup that works in many normal cases, but the stop is still sometimes too hard and not acceptable. But, the next day they are devastated again when they start in the morning from one of the end stations with the same train set, but with cold brakes, and the train stops short every time, the first ten stops. And even more devastated the day after when they get another train set (totally more than one hundred train sets), where the found that this set of PI parameters does not work, even with warm brakes.

But, the team is still trying to fix the software, because they think there is some combination of regulator parameters that will fix it all.

In next blog post, the team is home again, licking their wounds. C u soon.