As part of the project a software developer should always “Eat his own dog foot”: test and use the application that is being developed. It’s important to know how your own product works and feels. Usually this is not a big deal, every now and then it is needed to run the code and test if everything works as expected. With DynRow it wasn’t that easy: I’m currently injured on my knee, so it’s not possible for me to get on the ergometer and just row away while DynRow runs in the background.
I was able to test the application with testing data – The player data did not come from the ergometer but from a generic input which generated a constant pace. However when I first sat down on my ergo a few days ago and actually tested the application, it was a whole other thing: Testing data did not show that for example certain statistics were too small to see them while in motion. Testing data also did not show that the currently implemented bots do not work very well when actually rowing against them.
What I did was to row with a very low intensity, just so my knee could handle it. I then put my phone beside me during the training session and everytime I noticed something I paused and noted it down. One of the first things I wrote down was that the application does not automatically Pause when the user interrupts his workout, so there’s that… I assembled a list of around 20 issues which I afterwards rethought and created about 15 Github issues from.
Now I have a bigger list of things that I could fix and implement. The first iteration worked good: I fixed some of the bigger issues yesterday and tried DynRow afterwards: It improved a lot and felt actually quite good to use. It’s not that good that I would actively promote it for others to use, but it’s making progress. Now I only have to heal up my knee so I can do some more intense testing (and also be able to get my fitness level up again).