OFT helps debugging tracing chains at Elektrobit

At Elektrobit we were developing systems that had complicated tracing chains starting at product target documents then going down through system specification, architecture, detailed design documents to implementation, tests and so on.

While we already had a software in place that could do the tracing job and produce an HTML report, that tool was not meant for the fast round trips that you need when you work in an agile development mode. It would take minutes to run a trace, find the link errors, fix them and run the trace again.

One part of the problem is that the generated report was very exhaustive and to find specific problems we would use JavaScript controls embedded into the report to filter it down to a size where a person can spot errors. Since this was not persistent through tracing runs, we had to do it again after each run.

There was also always the discussion whether or not that toolchain could be used in projects where we had external development partners, since it was a proprietary in-house solution.

Out of this experience OpenFastTrace was born. We developed it in our spare time and as an open source software right from the start.

Our main goal as the name suggests was to speed up the tracing process to a point where continuous modify & trace approach would not only be feasible, but a pleasure to use. This meant we had to get a whole lot faster than the minutes that the predecessor tool chain took.

On the other hand we wanted to be able to locate problems faster than with the existing solution and have stable filtering.

The easiest way that came to our mind was to follow the Unix philosophy. So the first report we implemented was plain text which allowed us to pipe the output into whatever text manipulation tools we needed (like grep, sed and the likes). Consequently the first user interface was a command line interface.

When I first ran a trace from the architecture document to the documents above I expected the trace to come back fast, having run a good number of tests before. Still I was surprised just how fast it was. The result was there near instantaneous. I typed the command, hit Return and within below a second the result was there.

This sped up my hunt for tracing mistakes I made enormously. Where I had formerly spent one or two hours with each release to find and fix the errors, I was now done after a few minutes.