At Ruby Hack Night, January 28, 2016, we explored the theme of context switching while developing applications using the Ruby Gosu Gem. It was surprisingly enlightening.
Gosu is an amazingly simple way to build games in Ruby – it’s quite surprisingly simple to use. We came equipped with five functioning Gosu games of various states and qualities. This list included a Mario clone and a Galaxian clone. We formed into small project teams, consisting of two developer pairs each, with the intention of improving the games over 4 “speed sprints” (each sprint was only 40 minutes in length.)
The intention here was to:
- learn about working under tight deadlines and making trade-offs,
- improve our ability to work on code with which we were unfamiliar,
- learn to stay focussed on important tasks and suppress the desire to explore, and
- optimize our approaches based on the composition of our teams.
Some key takeaways are:
1. As developers, we find context switching to be difficult. This is because of we work at a level of detail that requires focus and concentration. Context switching, such as what we experienced in the workshop, is counter to our craft, especially when it is frequent.
2. Working in a pair or team provides opportunities to optimize our workflows for the dynamic conditions of development, and thus achieve a sort of synergy that achieves even better results.
3. By breaking our development into smaller tasks with predictable transitions between the tasks, we can alleviate some of the conflict and thus achieve better results.
4. Clear and concise code allows us to focus more quickly on the locations and nature of changes to existing projects (i.e. improves conceptualization). Code that is “smelly” (dirty), breaks conventions, or uses arcane features or nonsensical names (consider how difficult the Portuguese project was to work with) frustrates our ability to switch contexts.
5. Further to 4, user stories are sized to fit in a small number of functional points. The scope of changes to implement a user story would therefore be quite limited, as long as the code is concise. Our estimates of functional points therefore takes into account our estimate of code health. Poor code health begets higher estimates – like interest being charged on your technical debt!
I want to thank all of the participants for their contributions to the event. – David