Skip to main content

Metric Driven Development

I am currently implementing a SLAM algorithm. It contains many sub-algorithms like tracking, mapping, and loop closure. It never archives an exact result, therefore directly comparing the result against an oracle does not work.
Some SLAMs are better than others. Some parts of one SLAM perform than some parts of others. I even can mix different parts of existing SLAM into a new one. And then, I didn't even start with configuring the system, which can make a lot of difference.
I suggest, therefore, besides TDD on the micro-level, MDD - Metric Driven Development - on the macro-level.
The scheme is related. I come up with metrics and build a harness for them. This means that I think about how to test the system before I start. Then I record sample inputs for the SLAM. The first result is as bad as it can be: it did nothing. From here, I start to develop.
This is done for every part of the whole and the whole itself. Every metric has to show something meaningful.

Comments

Popular posts from this blog

Futureproof Software

From here:  https://dzone.com/articles/the-secrets-of-futureproof-software Self-healing Self-patching, or more broadly, self-updating Backward compatibility Dynamic adaptation/ability to evolve over time Intent-based Made up of reusable futureproof components

Choose Projects you do NOT do!

Inspiration from FluentC++ Choose which project NOT to work on. Be clear what you want and which projects are toxic. Keep the Hedgehog-concept in mind. Be sure that you are a) deeply passionate about the project b) the project can be the best in the world quality c) you can earn money with it If one of the three points is not met and not realistic soon don't do the project. Play around with it privately. Maybe you can pivot there so that it meets the criteria.