Owning and improving what you have is a sign of maturity in software engineering — Is it?

Re-factoring vs. Re-Writing?

A lot of times we heard the talks about “Never be satisfied” in the context of innovation and driving your teams forward.

In that context, this is totally fine, but when this mindset gets blindly used in the software engineering low level details, then you could be constantly re-writing code without taking the effort to truly understand it. Is this the right thing for business? Is it costly?

Re-factoring means that you took time to understand what you have, and you are improving it.

On the other hand, re-writing does not necessarily mean that you took the time to understand the low-level details; it may mean that you went back to requirements and decided to re-write it without trying to understand the low-level details. There could be something in those details that you need to know so you don’t make the same mistake again in the process of re-writing it.

At the end of the day, if you are constantly re-writing code, then there is no sense of ownership. Just put yourself in the shoes of the person who wrote some code that can be improved with some re-factoring and you still decide to re-write it. A few months later you may be in the position of that person where somebody else decides to re-write your code. How do we decide to draw the line because there is still business to support?

Please think about this as you are going through the existing code and consult with your tech leads and solutions architects. Let’s achieve the balance of re-factoring and re-writing.

Until next time,

Almir Mustafic