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, ... .
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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:
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!
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.