TheCodedWorld

Sad to say that I haven't been coding as much as I want to during the last weeks. There are a couple of reasons for this. One is that I have been sick. Three weeks straight of coughing and fewer that comes and goes. Terrible! You could think the reason for this is that I just sit on my butt all day coding. But that is not true. I actually have been training long distance running three times per week during the last year, aiming for completing a full marathon in 2019. Anyway, hopefully I will get well shortly and stay that way for some time now. The second reason for me not coding as much is that I have been working with bugfixing/support during the last month. It is not something that I, or anyone(?), enjoy doing for longer periods of time, but sometimes you just need to. So, not much to say about TDD this time. But I will stick with it. I am planning to do some of the more advanced Katas on Codewars or Hackerrank and those can be good candidates for TDD.

One of the chapters in the famous book "The mythical man month" by Fred Brooks is titled "Plan to throw one away". The idea is that you should plan to throw the first version of your software away, and then re-write it the way it should be. It is very likely that you will end up with a better written product and the total time spent will be less than it would have been trying to fix all mistakes you made in the first version. It might sound counter-intuitive, but throwing the first version of the product might save you both time and money. It should be noted that the first edition of the book was published in 1975, long before agile software development techniques and things like Scrum became the reality of every software developer. However, with Scrum we've seen to forgotten this completely. We do not plan to test things out for one sprint, then throw it away and do it correctly the next. No, we want to deliver costumer value every single sprint, all the ti

Recently I have been writing some completely new code using TDD (no dependencies to existing functionality). With Kent Beck's money example fresh in memory I realized that I should write the tests, defining the wanted functionality, without any thoughts on the implementation. The application code should then be written without any constraints on number of classes etc. When I wrote the application code I tried a number of different approaches, adding and removing classes along the way, until I ended up with something that was clean and easy to extend when needed. All the time I had the tests running so that I could feel confident that my changes did not break anything. Also, as I kept adding new tests, some of the already existing ones became redundant, so I removed them to avoid duplication. Now, the tests does not cover every single edge case, and I am still unsure if it is the responsibility of the tests written during TDD to do that. Any thoughts on this are welcome.