Software developer blog

Changing requirements

About 9 month ago as we were preparing for the next Coderetreat Athos came up with an idea for a game he called the changing requirements. I liked the idea from the get go, since I think that in becoming a software developer the hard part is learning how to react to business needs. At least for me that took a lot more time than to write my very first game in QBasic as a little kid.  The really sad part is that one can graduate university without ever even realizing that he is missing one of the software craftsmens most important virtues.

What I found really appealing in the concept of Coderetreats was that it provided a forum for professionals to learn about techniques that can help in dealing with change. On the other hand it is about getting away from the pressure of getting it done, and by that it takes these techniques out of context. It's kind of the price for letting you concentrate on practice.

The changing requirements game is something we like to play as the very last session of a Coderetreat. By that time the participants have learned a lot of new things, and have become familiar with game of life. The session is 90 minutes long  - enough time for a pair to finish the job - but we come up with requirement changes at times when it's already too late to incorporate that into the design without substantial refactoring. If the pair has already learned how to do evolutionary design they will easily adapt, otherwise they will have quite a bad time. Either way they will hate the facilitator for a second, and then they will get really excited about the problem.

First time we played this game it didn't turn out so good, since we introduced the hexagonal game of life as a requirement change to a team that have not tried to implement alternative topologies before. From that moment they spent the rest of their time trying to figure out how to represent cells. So don't do that...

The second time it went much better. Here is what we did: The first requirement change is introduced when people start to create finite 2 dimensional arrays as the board: sorry, but we need an infinite world. After that, when the twos and threes start to show up in the code representing the rules of the game we ask the teams if they could allow us to define alternative rules. The next change encourages them to get away from primitives: we need to know the age of each living cell. (Note that they can still do it with primitives, but it will get really painful soon, if they do that.)

The last requirement change comes at about 70 minutes, when everybody is almost ready: the cells have a weight. In the beginning we set the weight of each cell, if a cell stays alive than it's weight does not change, if a cell gets born, than it's weight is the average weight of it's living neighbours. This last change request will force a serious refactoring, since up until now we only needed the number of neighbours, and never the actual neighbours themselves.

Changing requirements

Developers trying to fit the next change into their design at the 4th Coderetreat in Budapest.

When the session was about to end I stood up and introduced one last rule: 3 minutes till the next trade show, where we want to show our product to the customers. We need to have a working software (i.e. all test need to pass) with as many features as possible, but you are allowed to temporarily down scope by ignoring some of the change requests. The trade show idea was totally spontaneous, but that one caused the most excitement. The pairs started to debate, and they worked really hard to either go back to a previous version, or to get to a stable state.

What turned out to be even more interesting for me, were the things people said during the retrospective of this session. The lessons they learned were simple, yet important. It's not a good idea to react to changes right away. Instead add the requirement changes as stories on your backlog, and start adding them once you have tests with flying colours for the other requirements. If you have tests it's a lot easier to refactor, and adapt the design to fit new requirements.

To sum it up: although this session contradicts the rules of a Coderetreat in that it actually encourages one to finish the job as far as possible, it can be very instructive when participants have already learned some of the agile practices, but have not yet mastered them to a level where they are already second nature. A session like that can help in showing them how the practices they learned during the day will make work easier in real life situations.