Regular Workouts Keep Your Code Fit.

weight bags on the floor near wall
Photo by Adam Wilson on Unsplash

Many of us have seen it and worked with it: a code base which grew over time and accumulated structures that hinder progress. Sometimes this originates from legacy code adopted from other teams. Many times it's not the others to blame and you have to face the ugly truth: you forgot your quality standards and your code got out of shape!

The complexity of code is directly linked to the domain's complexity. If the domain you are working with has a decent amount of complexity, chances are the code produced has similar or even higher complexity. With design and architecture patterns this can be translated into structures that make things manageable. Unfortunately, we humans tend to be lazy and over the course of a long project might neglect principles we had in the beginning.

Ideally, when developing in an agile setup, the team strives to conclude each sprint with a product increment that has the highest possible quality. Requirements got analysed, structured and dissected into relevant parts for the software. Open requirements and questions led to assumptions being made and to built around them accordingly. If potential future requirements are known, those got also included into the software design to support future development. With a sane amount of test coverage, new components got integrated into existing code base and is safe guarded for future changes. This approach repeats and is the only way to allow the team to publish software into production with confidence sprint after sprint.

So long for theory.

Add Reality to the Equation

Agile projects often don't follow the ideal path. Reasons can be manyfold. That's perfectly fine and actually part of being agile to not follow a predefined fixed plan. As months pass during the project, the development team may overlook the need to refactor crucial parts of the application, when business is constantly prioritised the highest. This then leads to technical debt pilling up and in the worst case hinders allover progress.

The development team is responsible for code quality in an agile project. But how do you get your quality bars raised again, after some time has passed with not giving enough attention to code quality?

The team could start adding technical items to the backlog (please don't call those items user stories, because usually there is no user involved). With those items in the backlog, they can be planned for upcoming sprints. But remember, we are in a situation with business being prioritised the highest in most cases. So what usually happens is, the team agrees on a portion of the sprint for technical items. This then works well for three or four sprints. And then reality kicks back in again and the business requirements push down all that is not absolutely necessary.

Workout Regularly

How about we treat our code like we treat our bodies? If you want to be healthy and fit, you have to workout regularly. As long as you don't want to become a bodybuilder and attend the championships to show-off your pectoralis mayor, it is sufficient to do medium intensity trainings on a regular basis (but don't take my advice without seeing a professional in the field of human health). This can be easily applied to developing software and be integrated into your sprints.

The first thing to happen is, the team needs to recognise the need to become active (just like with your personal health). You should find time to analyse your code and to collect everything that needs clean-up, re-design, re-structuring or just better test coverage. This list should be accessible to the whole team and is the workout plan for the upcoming sprints.

Before you start with your workouts, you have to be perfectly transparent with everyone involved -- especially with the team's product owner. Not making those efforts transparent is as bad as collecting technical items in the backlog that never get worked on.

The team should find a time slot which works for every sprint. You will want to plan with a couple of hours each. Maybe every second Friday afternoon or the first afternoon after planning in the beginning of a new sprint. Block this time in your calendars ahead of time. Making time for this kind of work is important, otherwise it probably won't happen.

You may also like to add a item to your sprint board if you not already have one. But don't try to estimate the item or add story points to it. This is supposed to be an ongoing effort for a couple of weeks going forward. Treat it more like your regular sprint ceremonies, which you also don't put estimations on. It should be more like a time box. If you feel you have to reduce the regular sprint items a lot to make room for the code workout, think about a shorter time box. Though, bear in mind that, depending on the tasks for the workout, the team might need a minimum time for it to be able to finish one session with meaningful results.

Attitude and Effort

With the next (or first) code workout ahead, find a place where all developers of the team can gather. If you happen to be in a parallel universe without active pandemic, you could find a cozy spot with a big screen everyone can sit in front of. Otherwise, choose your favourite video conferencing tool which supports screen sharing and is known to be reliable for the time span of the session.

How the team performs the code workout session in detail may differ. Pair Programming and Mob Programming can be a natural fit for this. It's not really important how it's done. As long as the team is comfortable with the method and the main focus during the session is to improve code quality. The latter is the important aspect here. You want to work the code.

Again, this is a code workout. You workout the code. Hence the name. This is not a hackathon, where you try out cool new stuff. This is also not a coding dojo, where you try to improve your coding skills. Pay close attention to not mix ideas and keep the focus.

A code workout session is successful, if the team manages to completely finish one planned task. This is not any different to regular work during the sprint. For example, this could be a refactoring of one sub-package or sub-module towards an improved code structure. Or it may be a refactoring which reduces complexity of a certain component that felt cumbersome working with before.

Everything resulting from the code workout, should also be integrated into your main branch right away. Don't let it on a branch waiting until the next session. Due to the nature of changes introduced, there is a high potential for conflicts. That's also the reason to do the session with everyone from the team. You don't want someone from your team work separately on something else in the same code base at the same time as the code workout session done. You would just end up with a huge diff and headaches. The last action of a session is to take the worked task from the code workout list. Maybe you want to recap the session or think about the next item briefly.

The next session can continue where you left the last session, if possible. Maybe you have any learnings from the last session. Take some minutes to find out if you have to adjust the method. You may also want to check the last results again and see if there is anything left to do. Then just start with the next item on the list and workout the code.


Reading Tip

If you buy something from the seller via the link above, I get a commission from your purchase. For you the price remains unchanged.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.