4 ms·
Refactoring is (as Uncle Bob puts it) an implementation detail. That means management doesn't understand its value, so they should not be expected to take owner
by justanotherc 7y ago
Refactoring is (as Uncle Bob puts it) an implementation detail. That means management doesn't understand its value, so they should not be expected to take ownership over it.
As engineers we need to just do it, and build it into our tasks.
A car mechanic doesn't ask the customer if its ok if he calibrates his widgetometer -- he just does it as part of the job. The customer has no idea what a "widgetometer" is (neither do I), so of course they will push back on paying for it to be fiddled with.
- Rapzid 7y agoThis is the approach I typically advocate. I actually like to think of quality, depending on the project of course, a bit like an LSM tree.. Well, in the sense that I expect new code and features to be a bit more loose and chaotic. Over time though, the chaos should be reduced and "compacted" if you will as code is revisited and patterns emerge(rule of three). Of course a certain amount of developer continuity and familiarity with the code helps a lot with this approach.
- Benjammer 7y agoImo, this is silly and condescending. I've worked with plenty of team leads and PMs who understand the value of refactoring at some level. In your analogy, I would say the implementation details would be things like which wrench is used, which hand turns the wrench, how many turns it takes to loosen/tighten something, exactly how you hold the bottle of widget fluid to pour it into the right widget fluid opening under the hood, etc. The concept of which widgets are being fixed seems crucial to the full picture of understanding the state change of the system (car) before and after the work is done. The owner is paying for the state change in the system.