DEV Community

Discussion on: How to refactor without overtime and missed deadlines

Collapse
crebelsky profile image
Christian Rebelsky

They'd have a concrete solid argument – numbers. Totally reasonable, who wants to pay for a prettier code, while software remains literally the same? As I said in the beginning, refactoring won't necessarily bring any billable value to a product.

Not 100% happy with this argumentation, depending on lifetime of code and project. Just sell it to save working hours for all devs involved. A couple of scenarios that come to my mind are:

  • reduce debug time - as you already mentioned
  • making parts of the application reusable to save time in upcoming developments
  • reduce the amount of time onboarding new colleagues

So for most code bases (at least the ones i came across in recent years), it's in my opinion good to start with some initial dedicated time and it's possible to sell this if necessary. If this is done and matches the code quality guidelines of the team (if present), it's fine refactoring on the go. As you implement new features, make improvements, ... .

Great article - thanks!

Collapse
nikmilson profile image
Nikita Milyanik Author

Oh, as a developer, I don't like this rationale either. Unluckily, I experienced it quite often so far. It doesn't mean by any chance a management's failure, though. Probably I wasn't looking quite convincing, 'cause find the argumentation still partly reasonable.

The scenarios you suggesting might work quite well. Especially if you're starting working on a stale codebase and sure about the upcoming area of activity. But still, why wouldn't you just keep those things in mind to dev team and serve it to the management under a sauce of a higher estimation due to poor code quality? From my naive point of view I would rather buy that, if I were a manager.

Thank you! I'm glad you like the article.