As one of the oldest products in Redgate’s portfolio, Prompt has been developed by dozens of engineers over the years. Because of this, its codebase is more than a little complex, and there are some areas of code that have been left alone for so long that no one really understands how they function. In any codebase, each team member will always have expertise in particular components, but in the Prompt team we want everyone to be comfortable and confident in tackling issues across all components. To help with this, we recently introduced Prompt “Domain Investigation Time”, a dedicated four-hour block devoted entirely to gaining a better understanding of the darker corners of Prompt’s codebase.
Perhaps the most extreme example of these “dark corners” is Prompt’s SQL parser, one of the cornerstones of Prompt. In fact, when we identified the key areas we wanted to understand better, the parser got the most votes. Therefore, as part of our third Q2 objective — “We want to make Prompt easier to maintain” — one of our key results was to reduce the number of parser dependencies from 6 to 5. Given the complexity of the task, we felt the best approach to attacking it was to do so as a whole team. On Tuesday 29th May, we spent an entire afternoon taking the first steps towards achieving this KR, using a technique known as mob programming.
Mob programming is a software development paradigm in which “the whole team works on the same thing, at the same time, in the same space, and at the same computer”. It’s essentially a levelled-up version of the well-known pair programming technique. It can lead to a variety of benefits, such as improved communication (as everyone is in the same room already), better decision-making (as the whole team can work together towards the best solution) and a mitigation of the risk of introducing technical debt. We also employed a “driver/navigator” system, in which one person operates the keyboard and mouse — the driver — while the remaining team members are navigators describing what they think the best course of action is. We then rotated roles every 5 minutes.
Obviously, there are a few downsides as well, chief among which is the difficulty of getting an entire product team into the same room for an extended period of time. It can also be quite difficult being the driver, as your role is to maintain impartiality and avoid engagement in the active discussion. There’s also the risk that the biggest personality can dominate the whole process. There are various steps that can be taken to mitigate these issues, but I won’t discuss them here.
During the session, we primarily focused on gaining an understanding of the current state and implementation of the dependency we wanted to remove. We then implemented several significant refactorings using ReSharper, as well as extracting some of the more complex logic into individual methods that were easier to understand and will therefore hopefully be easier to maintain. As a bonus, we also identified a broken unit test that was using an invalid syntax.
Overall, we felt as a team that the mob programming experiment was a great success. In fact, we enjoyed it so much that we’ve planned a follow-on session which we hope will get us even closer to our goal of completely removing a parser dependency. There’s definitely scope to tweak the process too, such as rotating on 8 minute intervals rather than 5, so mob programming can be tailored to a team’s needs. We’re also planning to trial another methodology (the Mikado Method) as part of that session, so maybe this blog post will be the first in a series?