There is always a better way of doing things: a new type of database, a new programming language, a new way to implement a form in React.
Even for senior developers -especially for senior developers- once they find a better way to do things, the most scary word in the software industry comes out of their mouth “refactor.”
Refactor means rebuild; it means redoing things to be where we are without a noticeable benefit that justified the intense fear of overspending and not hitting the deadlines.
Yes, it will make the platform more robust, and yes, in the future will pay off (because it will make things easier to code, or not.)
How do you measure the cost of implementing a better way? It has to be rooted in an existing cost: let’s say the developers are struggling with a form that never worked, that always was buggy, and users complained about it, that has more bugs than Beetlejuice… then it is a good candidate for refactoring.
If it took 80 hours of bug fixing last month, and the refactor will cost 160 hours in the following month, the math is simple: fix the damn form, and it will pay off in two months.
- Contrasting Traditional vs. Remote Team Management Tactics - 11/20/24
- The Role of Color in Brand Identity - 10/23/24
- Human-in-the-Loop for Bias Mitigation - 10/16/24