It was Monday, November 21st. I was performing a code review using the Bitbucket system.
The risk of using IT terminology.
I saw a comment from a colleague to a change of another colleague. The comment was a valuable one for a known improvement we wanted to do, when we have the time. This was a candidate for a future sprint.
The feedback was valuable, however the suggestion stated another quick fix in the function which was not related to the functionality developed. Should the developer add this quick fix to a code change or not?
Why we like to do it?
Working on a complex business domain means there is a lot of planning and research before the code development can start. The development team loses a lot of time in communication with the customer or with other stakeholders.
And this is one of the reason quick fixes are tempting, they are easy to change and are right in front of us. There is no need for a research and no need for communication with external people. The amount of dopamine versus the time spend is huge. And the development teams feels like they had accomplished something more and provided additional value.
The hidden risks
If you work in a complex business domain, then there is a higher risk, a fix to one part of the code to introduce side effects on another. Such issues are called regressions, and they are a big issue for the end user, who already use the solution in a production environment.
The team who also work on such a solution looks bad in the eyes of the customer.
Recently the regressions introduced in new software versions had increased. One example is the Windows 10 updates, which constantly suffer from quality issues.
This affects the reputation of the team which develops that product.
If we see a lot of opportunity for quick fixes, it might be better to plan architecture change instead. This would help us to not lose time with constantly refactoring legacy code and apply the new knowledge from the business and the system we had gained. By updating the architecture, our goal must be to speed up the development process and reduce the risk of future regressions.
A real world examples
What we can do to mitigate such issues?
As a certified scrum master, I know that it’s very important for the team to focus on what they consider “done” for the resources they have at that moment.
If there isn’t an established definition of done in the company, the team can at least create one for themselves. This will help them and limit the future need of quick fixes.
The other systematic approach that must be introduced is the architecture review and proposals for architecture changes.
The product is constantly changing and evolving as the underlying business. It is tempting to do quick fixes and continue delivering value to the business. Over time, this approach will slow down the development, because more and more patches needs to be introduced. This will also have a negative effect for the development teams’ reputation.
Aleks Vladimirov
Solution Engineering Manager at Thales | Senior IT Professional | Startup Mentor and Product Manager
