3 ms·

Sometimes it's very hard to justify why a project needs to be done especially if it involves back-end refactoring. Additionally, there are many ways to implemen

by gitah 12y ago

Sometimes it's very hard to justify why a project needs to be done especially if it involves back-end refactoring. Additionally, there are many ways to implement a project; the fastest ways usually involves a lot of un-maintanable hacks. However, your project stakeholders won't care how terrible your code is as long as the project works If it was up to business, they would have developers crank out features non-stop without time to go back and clean up technical debt. The root cause is management not understanding how software development works.

austinz 12y ago
Absolutely. I can't agree with this more. A long time ago I worked on a codebase where (among other problems) developers who wanted to extend a particular feature needed to modify five or six different methods spread across a number of files. (This feature was basically a pipeline that took in JSON from our servers and translated it into views to display to the end user.) Forgetting to modify even one of these files would lead to code that compiled but would throw cryptic errors at runtime. Developers from outside our team who wanted to work on the codebase and extend the feature would reliably lose several days to either the problem I described above, or hunting around the code trying to piece together how the feature worked from the disparate implementation details. Eventually, I took some time off and refactored part of the feature so that only a single source of truth needed to be modified in order to extend it. As a bonus, this refactoring made the mapping between data models and views in our application explicit, making the behavior of the feature significantly easier to understand. I didn't ask management or submit any sort of formal proposal; I did this on my own time because I had become fed up with the limitations of the existing approach. After the refactor entered the codebase, the aforementioned bugs vanished, as did many of the questions from outside developers about what models corresponded to which views, or how the feature worked, or how to extend the feature in general. I tell this intentionally vague (and honestly quite pedestrian) anecdote not to brag (the refactor was reasonably straightforward), but rather because I wanted to emphasize the difference between feature work and technical-debt-payoff work. The refactor almost certainly saved a considerable amount of developer effort and increased code reliability. But how much so is not something that can be easily measured (if at all), unlike the impact of a user-facing feature. Not only this, some combination of apathy and political pressure from external stakeholders tends to lead management to deprioritize paying off technical debt. Proposals to management to formally set aside time to address other issues of similar scope were pushed back repeatedly or dropped. PMs and product people can A/B test, gather analytics, get concrete data on hypothesis A versus hypothesis B when it comes to features. But it's rare that engineers get asked how much more quickly they could get their work done if they hadn't had to hack around unmaintainable hacks, or how much more reliable their code would be if bad design didn't muddy up the codebase or provide hiding spots for weird corner cases. Given how expensive software engineers are and how supposedly scarce they are, I'm honestly surprised that this isn't something management thinks about more.
- Joeri 12y ago
  Managers who don't know how to measure what they want settle for wanting what they can measure. Feature delivery is easy to measure, technical debt is hard to measure. Ofcourse, in the long run technical debt affects feature delivery, but people tend to look for causality relationships in the short term. That a decision not to allow refactoring slows down a set of features 6 months later won't be linked in a causality relationship unless proper root cause analysis is done.

by gitah 12y ago

austinz 12y ago

Absolutely. I can't agree with this more. A long time ago I worked on a codebase where (among other problems) developers who wanted to extend a particular feature needed to modify five or six different methods spread across a number of files. (This feature was basically a pipeline that took in JSON from our servers and translated it into views to display to the end user.) Forgetting to modify even one of these files would lead to code that compiled but would throw cryptic errors at runtime. Developers from outside our team who wanted to work on the codebase and extend the feature would reliably lose several days to either the problem I described above, or hunting around the code trying to piece together how the feature worked from the disparate implementation details. Eventually, I took some time off and refactored part of the feature so that only a single source of truth needed to be modified in order to extend it. As a bonus, this refactoring made the mapping between data models and views in our application explicit, making the behavior of the feature significantly easier to understand. I didn't ask management or submit any sort of formal proposal; I did this on my own time because I had become fed up with the limitations of the existing approach. After the refactor entered the codebase, the aforementioned bugs vanished, as did many of the questions from outside developers about what models corresponded to which views, or how the feature worked, or how to extend the feature in general. I tell this intentionally vague (and honestly quite pedestrian) anecdote not to brag (the refactor was reasonably straightforward), but rather because I wanted to emphasize the difference between feature work and technical-debt-payoff work. The refactor almost certainly saved a considerable amount of developer effort and increased code reliability. But how much so is not something that can be easily measured (if at all), unlike the impact of a user-facing feature. Not only this, some combination of apathy and political pressure from external stakeholders tends to lead management to deprioritize paying off technical debt. Proposals to management to formally set aside time to address other issues of similar scope were pushed back repeatedly or dropped. PMs and product people can A/B test, gather analytics, get concrete data on hypothesis A versus hypothesis B when it comes to features. But it's rare that engineers get asked how much more quickly they could get their work done if they hadn't had to hack around unmaintainable hacks, or how much more reliable their code would be if bad design didn't muddy up the codebase or provide hiding spots for weird corner cases. Given how expensive software engineers are and how supposedly scarce they are, I'm honestly surprised that this isn't something management thinks about more.

Joeri 12y ago
Managers who don't know how to measure what they want settle for wanting what they can measure. Feature delivery is easy to measure, technical debt is hard to measure. Ofcourse, in the long run technical debt affects feature delivery, but people tend to look for causality relationships in the short term. That a decision not to allow refactoring slows down a set of features 6 months later won't be linked in a causality relationship unless proper root cause analysis is done.