Today I had my first IPM (Iterative Planning Meeting). In general, it is a weekly meeting you have with clients to see what features they would like prioritized for you to complete in the next week. Because I am an apprentice I don’t meet with actual clients. Instead, my mentors Alex and Micah act as my clients. They gave me a list of tasks they would like to see done. I then had to make estimates on how long it’d take to get each task done. To make the estimates I had to choose an estimate of an optimistic time to finish, a realistic time to finish, and a pessimistic time to finish. The estimate to the client is the average of those times. As we all know, time is a limited resource, so the client picks out tasks (called stories) that total up to 40 hours and puts them in a prioritized order for you to complete over the next week.

The top prioritized task I received was something called The Bowling Kata. In martial arts, Katas are a series of motions done over and over again so that those motions become second nature. In coding, it is the same premise. You get a piece of code. The first time you do it you struggle through it as you figure out how to solve the problem. After that you dedicate a little bit of time every day to rewrite the code. The repetition makes it second nature to write out the code.

The Bowling Kata in particular helps ingrain test driven development workflow into my brain. Test driven development is the coding concept that when writing code you always start with a test. Let’s say you need to make a function that takes a number as its argument. It should increase that number by 1 and then square itself. You can start by making a test for 0. We know by simple math that 0 + 1 = 1 and that 1 x 1 = 1, so we would make our test check that the output of our function is 1. Only after we’ve created the test do we start writing the function. The simplest solution to that is to just have the test output 1 with no calculations. Congratulations! The first test has passed, but what happens when you put 1 in as an argument? We expect our output to equal 4, but it is just outputting 1. That means it’s time to rewrite the function. This time we can make it increase the argument by one, and then multiply itself by itself so that we get 2. Looks like we’ve solved this problem. But just to be sure we should add some other tests. What happens when you add a negative number? What happens when you put a float instead of an integer? These are all things that should get tested for. By completing these tests 1 by 1 you can develop your code incrementally and methodically making the code less cluttered. It also has the benefit that if you ever go back to refactor the code, you have test conditions already in place to check that your refactored code is working as intended.