7 ms·

I really like this extension of the concept of overfitting to codebases in general. I especially noticed this in libraries/packages that were "community owned"

I really like this extension of the concept of overfitting to codebases in general. I especially noticed this in libraries/packages that were "community owned" in a company--instead of one team owning the package and being the authority on deciding the long term roadmap and communicating with other teams about feature requests, deprecations, documentation, bug fixes, etc, the community at large, where "community" was very broadly defined as a team that for whatever reason had an interest in using/maintaining/adding onto the package, would collectively own the package. Naturally, the result was exactly the scenario you described. Each team hacked on their own bit of functionality for their specific purpose, while doing their best to not affect or break the increasingly precarious tightrope of backwards compatibility. There was no long term architectural vision, so there was a definite need for refactoring--and yet no team had the incentive to invest the amount of time needed to do that.The documentation was woefully incomplete as well, and few people understood how the entire thing worked since each team would only interact with their small fraction of the code.

tomelders 8y ago
Two principles I live by (much to the annoyance of my bosses) 1. Don't fear the refactor. 2. If you don't want to rebuild your entire application from scratch, don't worry, a competitor will do it for you. There's nothing wrong with creating something in increments. It's the fear of revisiting something that destroy's a code base.
- nicodjimenez 8y ago
  "It's the fear of revisiting something that destroy's a code base." So true.
  - thomasmeeks 8y ago
    Yep, when fear creeps in around modifying a part of an application it is time to have a very serious conversation about fixing that. It is one of the few cases where I find the refactor vs. creating customer value argument is more clear cut -- letting that fear linger is likely to spread to other parts of the code & turns into a human problem pretty fast. Fixing might be a presentation, tests, documentation, refactoring, rewrite, deprecation, whatever. Just don't let it languish and the fear grow.
- vincentmarle 8y ago
  Your bosses might be right. Technical debt, much like regular debt, can also be used as leverage to quickly gain a competitive advantage. While your competitors are busy refactoring/rebuilding perfect applications without hardly creating any more customer value, the scrappy startup that writes piles of spaghetti code might be building exactly what customers want. Code quality != business value.
  - hackits 8y ago
    Business is mostly a math's problem and most programmers don't really understand why they go to work.
  - guiriduro 8y ago
    > Code quality != business value I don't think that's a given: in some circumstances code quality absolutely is business value. It might be better to say code quality can be, but isn't always, business value. As ever, context is the deciding factor.
    - blauditore 8y ago
      Well, I would say technical debt is similar to the classic kind of debt: It may give you short-term advantage (liquidity), but on the long term, there's interest on it. If not paid off, it grows exponentially. So yeah, technical debt can be used as a tool, but it doesn't come for free.
    - williamdclt 8y ago
      I really don't think so, apart from exceptional case (if you're selling your code to another dev maybe), code quality is never value to the user. That's not to say that good code quality is useless of course, but the usefulness of code quality is not in the business value.
  - sudhirj 8y ago
    Technical debt is already has similar business concept in "expensive" money - Funds that you raise from VCs while in distress on bad terms because there's no other way to do what needs to be done fast enough. Programmers paid with expensive money trying to argue that they need more time to write high quality code because 'future' will seldom win that argument.
- hyperpallium 8y ago
  oblig. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- collyw 8y ago
  Indeed. I used to be scared of database changes in case something went wrong. Now I realise the worst thing to do is to hack code on top of a poor database design to make up for it. That usually ends up far worse.
- scalesolved 8y ago
  I wholeheartedly agree! Companies that delay tackling technical debt still ship features, they get slower and more error prone development as time passes. As they still keep shipping they can fail to see how much faster they'd be shipping 6 months down the line if they tackle debt which adds weeks to each feature being developed. I've expanded on these thoughts before on my blog about technical debt inflation if anyone is interested https://scalabilitysolved.com/technical-debt-inflation/ https://scalabilitysolved.com/technical-debt-inflation/
- matwood 8y ago
  > 1. Don't fear the refactor. Like most things in life, there is a balance. I have argued against large refactors many times. Often wanting to do a refactor is just a thinly disguised excuse to use some new technology (I'm as guilty of this as anyone else). Anytime a refactor comes up my goal is to figure out why: 1) What will the refactor fix? 2) What will the refactor potentially break? Are there tests around critical functionality? 3) Does the group proposing the refactor really understand the ins and outs of the application? When new people come into a system they often want to change it to fit their mental model of the problem, and miss subtleties of why the system is a certain way. That being said, I evaluate small refactors anytime I have to touch a piece of code.
  - kochthesecond 8y ago
    I am more inclined to your sentiment. Now there is no excuse for badly formatted code and being a lazy slob, and I never use the word refactor in the sense it is used here. I often _redesign_ old code to meet new requirements and to support new features, but I would not call it refactoring. I always strive to leave the code better than when I found it. But I would not name it refactoring.
taurath 8y ago
And one can extend that to businesses as well. How many established companies have been laid low by someone with a new process built in a more modern foundation.
- jopsen 8y ago
  It would be interesting if someone actually had data on this? I suspect this is something "software engineering" researchers might study.
  - taurath 8y ago
    Whatsapp is a prime example in the tech vs tech space - ride-shares vs taxi services, automated freight loading, fedex vs ups in terms of automating their package sites. An old factory with 1000 workers not being able to compete on a cost basis with a new automated one is the story of the last 50 years I feel.

tomelders 8y ago

Two principles I live by (much to the annoyance of my bosses) 1. Don't fear the refactor. 2. If you don't want to rebuild your entire application from scratch, don't worry, a competitor will do it for you. There's nothing wrong with creating something in increments. It's the fear of revisiting something that destroy's a code base.

nicodjimenez 8y ago
"It's the fear of revisiting something that destroy's a code base." So true.
- thomasmeeks 8y ago
  Yep, when fear creeps in around modifying a part of an application it is time to have a very serious conversation about fixing that. It is one of the few cases where I find the refactor vs. creating customer value argument is more clear cut -- letting that fear linger is likely to spread to other parts of the code & turns into a human problem pretty fast. Fixing might be a presentation, tests, documentation, refactoring, rewrite, deprecation, whatever. Just don't let it languish and the fear grow.
vincentmarle 8y ago
Your bosses might be right. Technical debt, much like regular debt, can also be used as leverage to quickly gain a competitive advantage. While your competitors are busy refactoring/rebuilding perfect applications without hardly creating any more customer value, the scrappy startup that writes piles of spaghetti code might be building exactly what customers want. Code quality != business value.
- hackits 8y ago
  Business is mostly a math's problem and most programmers don't really understand why they go to work.
- guiriduro 8y ago
  > Code quality != business value I don't think that's a given: in some circumstances code quality absolutely is business value. It might be better to say code quality can be, but isn't always, business value. As ever, context is the deciding factor.
  - blauditore 8y ago
    Well, I would say technical debt is similar to the classic kind of debt: It may give you short-term advantage (liquidity), but on the long term, there's interest on it. If not paid off, it grows exponentially. So yeah, technical debt can be used as a tool, but it doesn't come for free.
  - williamdclt 8y ago
    I really don't think so, apart from exceptional case (if you're selling your code to another dev maybe), code quality is never value to the user. That's not to say that good code quality is useless of course, but the usefulness of code quality is not in the business value.
- sudhirj 8y ago
  Technical debt is already has similar business concept in "expensive" money - Funds that you raise from VCs while in distress on bad terms because there's no other way to do what needs to be done fast enough. Programmers paid with expensive money trying to argue that they need more time to write high quality code because 'future' will seldom win that argument.
hyperpallium 8y ago
oblig. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
collyw 8y ago
Indeed. I used to be scared of database changes in case something went wrong. Now I realise the worst thing to do is to hack code on top of a poor database design to make up for it. That usually ends up far worse.
scalesolved 8y ago
I wholeheartedly agree! Companies that delay tackling technical debt still ship features, they get slower and more error prone development as time passes. As they still keep shipping they can fail to see how much faster they'd be shipping 6 months down the line if they tackle debt which adds weeks to each feature being developed. I've expanded on these thoughts before on my blog about technical debt inflation if anyone is interested https://scalabilitysolved.com/technical-debt-inflation/ https://scalabilitysolved.com/technical-debt-inflation/
matwood 8y ago
> 1. Don't fear the refactor. Like most things in life, there is a balance. I have argued against large refactors many times. Often wanting to do a refactor is just a thinly disguised excuse to use some new technology (I'm as guilty of this as anyone else). Anytime a refactor comes up my goal is to figure out why: 1) What will the refactor fix? 2) What will the refactor potentially break? Are there tests around critical functionality? 3) Does the group proposing the refactor really understand the ins and outs of the application? When new people come into a system they often want to change it to fit their mental model of the problem, and miss subtleties of why the system is a certain way. That being said, I evaluate small refactors anytime I have to touch a piece of code.
- kochthesecond 8y ago
  I am more inclined to your sentiment. Now there is no excuse for badly formatted code and being a lazy slob, and I never use the word refactor in the sense it is used here. I often _redesign_ old code to meet new requirements and to support new features, but I would not call it refactoring. I always strive to leave the code better than when I found it. But I would not name it refactoring.

taurath 8y ago

And one can extend that to businesses as well. How many established companies have been laid low by someone with a new process built in a more modern foundation.

jopsen 8y ago
It would be interesting if someone actually had data on this? I suspect this is something "software engineering" researchers might study.
- taurath 8y ago
  Whatsapp is a prime example in the tech vs tech space - ride-shares vs taxi services, automated freight loading, fedex vs ups in terms of automating their package sites. An old factory with 1000 workers not being able to compete on a cost basis with a new automated one is the story of the last 50 years I feel.