3 ms·

> A codebase that is brittle - meaning things break easily, testing is low, or where maintenance or new dev is difficult - is a genuine business problem. The so

> A codebase that is brittle - meaning things break easily, testing is low, or where maintenance or new dev is difficult - is a genuine business problem. The solution to that is engineering managers that can make a persuasive case I still think we need better ways of properly measuring this "brittleness". And also long term velocity and feature flexibility and other factors that are sacrificed when accumulating tech debt. Often these things are so vague that it really just comes down to a 1-vs-1 between the manager (who wants the feature out now) and the engineer (who may have been drinking too much microservices kool-aid). "I could have built this faster if we had switched to React last year" ok but roughly how much faster? Better measurements can make these discussions more objective, just like how scientific studies and data analysis are used in real politics. Of course we can't ignore the glaring issue with this paper specifically and it's relationship with Codescene, but I do wish to see more studies in this direction.

satyrnein 4y ago
"I could have built this faster if we had switched to React last year" ok but roughly how much faster? We can't even accurately estimate (ahead of time) how long it would take in the existing stack, much less in a different one.
- woojoo666 4y ago
  > We can't even accurately estimate (ahead of time) how long it would take in the existing stack, much less in a different one. We already try to measure these things with Agile and sprints. It's not perfect but many would argue it's better than zero estimation at all. However often the focus on sprints leaves long term investments like code quality out of consideration. More studies and data can provide better information on when these trade offs are worth it. Imagine if a large scale study came out that said companys that migrated to microservices ended up spending on average 2 additional months on migration if they delayed the migration by a year. Certainly this would be useful information for other companies thinking about the same.
danuker 4y ago
> And also long term velocity and feature flexibility and other factors that are sacrificed when accumulating tech debt Indeed. Perhaps spending 42% of time overcoming tech debt is steady-state, and paying the debt down shrinks the pie (i.e. customer base). It is an act of balance.

satyrnein 4y ago

"I could have built this faster if we had switched to React last year" ok but roughly how much faster? We can't even accurately estimate (ahead of time) how long it would take in the existing stack, much less in a different one.

woojoo666 4y ago
> We can't even accurately estimate (ahead of time) how long it would take in the existing stack, much less in a different one. We already try to measure these things with Agile and sprints. It's not perfect but many would argue it's better than zero estimation at all. However often the focus on sprints leaves long term investments like code quality out of consideration. More studies and data can provide better information on when these trade offs are worth it. Imagine if a large scale study came out that said companys that migrated to microservices ended up spending on average 2 additional months on migration if they delayed the migration by a year. Certainly this would be useful information for other companies thinking about the same.

danuker 4y ago

> And also long term velocity and feature flexibility and other factors that are sacrificed when accumulating tech debt Indeed. Perhaps spending 42% of time overcoming tech debt is steady-state, and paying the debt down shrinks the pie (i.e. customer base). It is an act of balance.