31 Jul

Checklists for improving the development process, part two: effects and reactions

A couple of weeks ago I wrote a blog post about checklists and how I created several checklists of my own to improve the way we handle pull requests. Today I’d like to share the results of the first weeks’ trial period: which effects did the checklist have on the development process and how does the team feel about them.

Here are the two checklists again as I originally drafted them:

checklist for branching

checklist for creating pull requests

Effects on the development process

After I had read so much about how checklists seem to be able to work wonders in other professional areas, the results of the first week trial period were somewhat sobering to me: during this week almost everything happened from a broken build to changes not being forwarded to the global common solution. Well, you cannot change a programmer’s habits overnight, and to be fair, not all of those incidents were caused by not using the checklist…

As the weeks passed on, however, there were several situations in which the checklist helped me detect changes that I had forgot to forward to the global _common solution, that would have been overwritten by the next running of the _common solution gulp task. And I was delighted to observe that almost all of the Pull Requests had the latest master branches merged into them. Also, there were much less cases in which some other branch than the master branch ended up in a Pull Request, and if there were, this was absolutely necessary and explicitly allowed.

What the team members think about the checklists

Even though the checklists have undeniably shown some positive effects, I know that not everyone uses the lists at all times. To be honest, every now and again I catch myself thinking ‘do I really need to go through that checklist now?’, especially if I am in a hurry or think that I have already done all the steps. But someone needs to set a good example…

So, I think while we generally agree on the importance of executing the steps set down in the checklists (haven’t we all been bothered by merge conflicts because we forgot to merge the latest master?), we consider it somewhat below us to actually use the list for that. After all, we are all smart developers who have coped without checklists for many years… so we just try to remember everything by heart, and maybe save the couple of minutes it takes to open the checklist and make sure we REALLY have done everything that the list requires. Needless to say that this is not exactly what a read-do list is meant for…

Conclusion

Even though the checklists are not used as regularly as I’d have wished for, they have increased the team’s awareness for the necessity of executing these steps. It is still better if the steps are done by heart and in the wrong order, than if they were not done at all.

We all generally agree that checklists are a good idea and that they are helpful, and we all know in our hearts that actually we should be using them. I firmly believe that if we continuously optimize the checklists and constantly adapt them to our processes, the acceptance of them will grow and we will slowly get accustomed to using them.

Share this

Leave a reply