Four Reason to Change your Software

#refactoring #csharp #programming #cleancode

CLEAN CODE & REFACTORING

Four Reasons to Change your Software

Four Reason to Change your Software cover image — Created by [Stories](https://www.freepik.com/stories)

Michael Feathers defines four main reasons to change your code in the book Working Effectively with Legacy Code. I found those few paragraphs interesting, and I would like to share them with you from my perspective.

Four main reasons to change are

Adding a feature
Fixing a bug
Improving design
Optimising

Adding Feature and Bug Fixing

original pictures by [Stories](https://www.freepik.com/stories)

The most typical reason to change software is an adding of the feature. Your software is acting one way, and the boss or client needs it to do something else.

At first, adding a feature may look like an easy task for both sides. Friction between the developer and the task assigner began when the assigner thinks it is a bug, but the developer sees it as a completely new feature.

At the moment when I am writing this article, I am also working on a form-based information system, and new task recently appeared in the mailbox. The client wants me to fix the focus behaviour of textboxes. He thinks that every time he clicks or tabs into a textbox which contains a text, the whole text should be already selected or as he said; “it should be blue”.

As the developer, you know that this is not typical behaviour of textbox and you will have to make changes. Depends on the framework you are work with, the task can take a few minutes or a few hours, and you may come out without a solution.

It might seem that difference between adding a feature and bug fixing is just the dilemma about the contrast of the point of view. A task stays the same, and you still have to complete it one or another.

But some companies are tracking developers time, for example, for invoice calculations or quality initiatives. Such difference decides if the company will bill the customer for a new feature or not. Bug fixing can be part of the contract with the customer. In this situation, the determination of difference crucial.

Design Improvement and Optimisation

Created by [Stories](https://www.freepik.com/stories)

First of all, don’t get me wrong. By saying word design, I mean a code design, no design of user interface.

Design improvement is a different kind of software change. It is driven by the goodwill of the developer, no by the boss task.

When we want to alter the software’s design to make it more maintainable, we want software behaviour to keep untouched. By changing a design, we may introduce a bug. Fear of introducing a bug leads to intact code segments which stay the same since the beginning and will rot.

As developers, we grow and knowledge of our craft rise. Time goes, design of new code is better, and one day task will appear for adding a new feature into old code parts. We can clearly say that such situations will once in a while come out. Such a position always motivate me to improve the design, but I am too afraid of dropping behaviours, and I will not do any. Again.

Side note: if you like thinking about the craft itself — when to refactor, when to leave code alone — I share short, free lessons like that in The Claude Code Memory Starter, a tiny email series you can join in one click.

Refactoring

Developers fear of changing code drives the creation of whole the discipline named refactoring. Refactoring is also the main topic of the earlier mentioned book.

The idea behind refactoring is that we can make the software more maintainable without changing behaviour if we write tests. Tests will serve as watchdogs. If any test fails while you improve a design, it indicates that you unwillingly drop a behaviour.

Code should be cover by the collection of tests which will keep watch on application behaviours. We should refactor in small steps, and continuously run a set of tests that will keep us informed.

The critical thing about refactoring from a change point of view is that there aren’t supposed to be any functional changes when you refactor.

Optimisation

The optimisation is like refactoring, but with a different goal. We want the functionality to stay the same, but the goal is to increase performance. Optimising can lead to dropping a behaviour and introduction of bugs too. We must apply the very same rules as in the refactoring process.

Summary

Fight between “it’s a feature” and “it’s a bug” is endless. Correct identification of the problem could lead to the rise of the company’s income or vice versa.

Refactoring and Optimizing are essential disciplines of code improvement and reasons for changing code. It has to be done slowly, wisely, and with the collection of tests which are going to watch your back.

One way of improving code design is to take advantage of design patterns. I wrote a few pieces, and you might find an interested in reading them as well.

Decoupling with Chain of Responsibility Pattern in C#

The Chain of Responsibility Pattern allows us to easily separate dependent parts to make code more extensible and…medium.com

How to manage states with State Design Pattern in C#?

Everything you need to know about State Design Pattern in C# at one place.medium.com

Daniel Rusnok's Newsletter

Every month I will send you an email about with list of my newest articles. It will be ofcourse the friendly links…www.danielrusnok.com