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

Lets imagine we are drinking too much coffee and our doctor is asking us to reduce the amount.
We can either stop drinking for a while and after a week or two continue with our old habit until we receive another reminder from the doctor. The other option is to change our lifestyle and habits and to never go back to the previous behaviour.
Another example is losing weight. Should we starve for 2 months just to achieve our goal? Or there is a consistent way to achieve the goal and to make the process safe and enjoyable.

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 Vladimriov is a Senior Software Developer, recognized Project Manager and Soft-skilled trainer and a coach.

Aleks Vladimirov

Solution Engineering Manager at Thales | Senior IT Professional | Startup Mentor and Product Manager

Aleks is experienced Product Manager with an engineer background and over 10 years of experience as a software developer. He works with different governments and is responsible for negotiation features and requirements, understanding the customers’ needs and supporting the senior management with regular reports and analysis. He held various positions starting as a software developer, moving to a team leader and software architect.

He strives in waterfall and agile environment alike. He is certified Scrum Master and Prince2 Practitioner and he knows how to design business processes and help teams optimize their work.
During his tenure, he had to wear many hats, prioritizing business requirements, delegating work and mentoring team members, creating mockups with Balsamiq, providing MS Project plan to the senior management.

He had worked in many international teams, located in the same city or distributed in different countries and continents. He had been a team leader of cross functional international team of 8 people.

In his current position, he is very much client focused. He has excellent presentation skills.
He delivers training sessions on presentation skills and leadership and he had helped hundred of people to improve their presentation skills.

He is also interested in creating more positive changes in the workplace by using entrepreneurship skills.
He had won startup competition where his team had validated and develop a business idea from scratch.

In his free time, he writes in his blog about effective product development.

Get the manual: "Leader as a Coach!"!

By downloading this handout you will be subscribed to our newsletter, which we send once per month. Give it a try, you can unsubscribe anytime.
Download