13 ms·

Technical Debt: How do you get out of the bottleneck?

81 points by nilsandrey 5y ago

tonyjstark 5y ago
While the article delivers nice explanations for what kind of technical dept exist, it stays very generic and hand-wavy for the solutions. Bringing "microservices" into the room is definitely not helpful. Ownership and setting a quality bar..., sure but how does that look like? As I developer I maybe have an idea but I also need to sell that to management. As manager I have an idea too but I need to convince my developers to strive for quality and sustainability. Sometimes I wish these articles would just state: Stop sprinting Also: document your decisions! If you have to write down and justify your (prudent) technical dept, you maybe catch some stuff before it's written in code. It also makes sure more people are aware of it. Additionally, it sometimes prevents CV driven development, which imho is a big problem in tech. Overall, documentation is a very underused tool. Finally: teach everyone (especially marketing) that software development is expensive, so everybody thinks twice before wishing for nice to have features done quick.
- sirwhinesalot 5y ago
  Could not agree more. The solution to tech debt is the one nobody wants to hear: Slow down! Steve Jobs' presentation of Snow Leopard should be mandatory viewing for every manager. "No new features" to a standing ovation. Customers actually like stable, responsive, and efficient tools, who would have thought? EDIT: > Bringing "microservices" into the room is definitely not helpful It's a pretty good way to increase technical debt. The microservices themselves might become small enough that it is easy to refactor some at a time, but then you have the actual deployment and communication infrastructure to contend with. And if you get that architecture wrong, oh boy you'll be begging to go back to a monolith in a day.
  - peakaboo 5y ago
    This happens constantly, the entire tech industry runs in whatever direction Google in particular is going. First it was Hadoop and all the pain that came with that, and now it's microservices and kubernetes and all the shit that brings into our tech stacks. Stop sprinting is good but also : stop following Google. You are not Google. You do not have the needs of Google. Just stop it. Pick the simplest tech stack you can find. This gives 100x more time to your developers to work on company solutions and not fighting technical complexity.
    - floydian10 5y ago
      > now it's microservices and kubernetes and all the shit that brings into our tech stacks. For all the talk about "no silver bullet", there's a staggering amount of folks who keep falling for it.
    - nwmcsween 5y ago
      The problem is you eventually need the things k8s offers and you end up implementing part of k8s, badly. I've seen bigish places that state "we aren't Google" as an argument to not use k8s, containers, etc but don't consider that their tech stacks are a Hodge Podge of bespoke glue, a mass of technical debt and a bus factor of generally 1 or 2.
      - sirwhinesalot 5y ago
        As someone who works on a hodge podge of bespoke glue, a mass of technical debt, a bus factor of 1, and a docker swarm setup, I don't really see how k8s would help ;)
      - majormajor 5y ago
        The question they should be asking isn't "is this tech stack perfect or a mess" it's "is this actively preventing, or about to prevent, us from meeting our uptime and cost and development goals"? The idea that a shop that built a messy system will suddenly build a non-messy system just if they pick up a new set of tools - that they don't have practice with anyway! - is exactly the silver-bullet fallacy. The system turned out messy because it's complicated, switching to a very complicated tool doesn't take away the complexity, it just changes the way you manage it. The last couple Kubernetes shops I worked at were that exact sort of hodge podge of custom glue with high tech debt and low bus factor. Just even doing something "simple" like "ssh into the box and poke around" when the two wizards are out suddenly has a huge learning curve. ;) So then you get into discussions of "oh you should've been using managed kube" or "oh, don't use TF -> helm -> kube, use [other way] of managing it" or blah blah. After you fuck it up a few time you might have enough useful experience so that you can build it well next time... just pray that by then we're still using the same tools. :D
  - tonyjstark 5y ago
    Snow Leopard is exactly what I had in mind when writing the comment. I remember watching the keynote and my own excitement about introducing no new features. Additionally to managers watching that presentation, software architects should mandatory have to work as normal developers in every project they designed for a a few months. Best, if it would be around 2 years after they came up with the architecture. If you don't taste what you cook, how can you learn? I fully agree on your points with microservices.
  - jamesfinlayson 5y ago
    > It's a pretty good way to increase technical debt. The microservices themselves might become small enough that it is easy to refactor some at a time, but then you have the actual deployment and communication infrastructure to contend with. And if you get that architecture wrong, oh boy you'll be begging to go back to a monolith in a day. I remember at a previous job, the monolith was drowning in technical debt. Someone decided the solution was Go microservices. Fast-forward 18 months and 95% of the functionality is still in the monolith, but there are now 25 microservices, and no environment (except production) where you can test everything together.
    - mattbillenstein 5y ago
      Coinbase?
    - KronisLV 5y ago
      > I remember at a previous job, the monolith was drowning in technical debt. Someone decided the solution was Go microservices. Fast-forward 18 months and 95% of the functionality is still in the monolith, but there are now 25 microservices, and no environment (except production) where you can test everything together. I have the opposite anecdote. Currently working on a monolith that's been around for 5-7 years, huge enterprise Java mess, like many others in the industry. The clients decided that they'd like to upgrade to JDK 11, newer frameworks, all of that shiny stuff. So for the past 4 months i've essentially been pulling my hair out and trying to rewrite significant parts of it all. When you have a monolith, you cannot upgrade the entire system if some parts of it break - even if i have, say, 200 dependencies but 10 break, i cannot move forwards with the updates and as a consequence am stuck with running on JDK 8 or even outdated frameworks. And, of course, you cannot extract those parts of the system out either because you'll immediately be hounded by developers who aren't welcoming of change and will find nitpicky stuff to tear both your arguments and efforts apart, actively sabotaging any potential successful outcome (potentially exaggerating here, but many do not enjoy change). Alas, there is probably some sweet spot to work towards from day 1. Not going crazy with microservices, especially due to how people interpret the "micro" part (e.g. service per person vs service per team, what the total count should be, domain modeling etc.), but not sticking to a single large monolith either. I think that sooner or later the industry will try grouping code into services based on the "type" of functionality - the weird PDF export and reporting logic will live in service A, other attachment upload/download logic in service B, the web API in service C, and the old legacy server side rendered UI in service D. That way, at least your efforts to update the web framework and JDK for it wouldn't be usurped by the PDF library not liking it. Then again, i've seen front end applications baked into back end applications instead of separate back end/front end deployments far too often, so i'm not hopeful about anyone genuinely exploring that approach anytime soon. Alternatively, i've actually written about modular monoliths before, in my article "Moduliths: because we need to scale, but we also cannot afford microservices": https://blog.kronis.dev/articles/modulith-because-we-need-to-scale-but-we-also-cannot-afford-micro-services https://blog.kronis.dev/articles/modulith-because-we-need-to...
  - fivre 5y ago
    > Customers actually like stable, responsive, and efficient tools, who would have thought? _Existing_ customers like these things (and they aren't wrong for liking these things). New business comes from the potential customers who weren't enticed by the existing feature set, robust or otherwise. You bring them in by adding new features. The retain/new business priority is often heavily weighted in favor of the latter. Retaining existing customers stuck with a crappy product ain't that hard between sunk cost/lock-in effects and the evergreen insulation of people with purchasing authority from the day-to-day pain inflicted by their purchasing decisions. A couple fancy steak dinners for middle management effectively papers over the cost of driving a department of ops engineers to cirrhosis several times over.
    - sirwhinesalot 5y ago
      You're absolutely right, and it makes me sad :(
  - mattbillenstein 5y ago
    Slowing down is really being able to say "no" to features for awhile while you re-architect the codebase - so you're delivering stuff at the same pace, but that stuff is not product-facing. I've been through this slog - sometimes it requires fixing what's there and other times, a rewrite. People hate rewrites, but it really is the best way forward in a lot of cases if done correctly.
- hinkley 5y ago
  If only the author had written a book about how to alter crappy code to make it better. Then maybe he could give us a plan!
- ac50hz 5y ago
  +10 This is my experience with many different systems. I’ve found that mentoring and personal development identification techniques for what to learn, and when, can be helpful. Inviting a developer to be part of the decisions made regarding their future may seem obvious, but in practice it’s often not done… And documentation… I’m known as “Just write it down,” but there is usually significant pushback… from all parties.
- noir_lord 5y ago
  > hand-wavy for the solutions This is Fowler (and Uncle Bob's) stock in trade tbh. Generic good advice that sounds plausible in a sane world. Without ever acknowledging that we actually don't live in that world.
keithalewis 5y ago
Techical debt is primarily about managing complexity, the bane of software engineering. Do not underestimate the value of having a coherent _theory_ about the problem being solved. Something everyone on the team understands and that can be taught to new hires. If you give a programmer a keyboard and a paycheck they will press on keys all day long.
- bokohut 5y ago
  And if complexity can be designed out from day zero with a clear and concise foundational development model to follow then the technical debt can be greatly reduced as well. This of course conflicts with the global rush into tech to build something as fast as possible to get to revenue and not investing the time proactivity to build for the long game. Planning and control are my two points that get extreme focus in designing that foundation as the world comes to learn the importance of these items impacting cybersecurity, fairly important now-a-days it seems, and so much more. If you know something works then no need to reinvent it every time.
  - hinkley 5y ago
    Designed out on day zero is the siren song of waterfall. Getting it right the first time is a very hard game to win. It’s best to save some of your energy for the times that really count. It’s always interesting to me when coworkers exclaim that doing the right thing is too hard. Reminds me of myself at age nine trying to get out of chores. More seriously though, “if it hurts stop doing it” is how dumb animals think. Pain is information. Ignoring it is dumb. Almost as dumb as giving up is. Just last week I was having a hell of a time getting some code to work. Running into a wall. Okay fine, I’ll write more tests. Still struggling. Oh hey, you know what would make this way easier? If I rearranged this code in the manner I thought about this morning but decided to not work on until tomorrow. If eating the code is difficult, there’s a point of very quickly diminishing returns where adding more logic to the tests is making things worse, and you should think about whether The code is too complicated to test. Maybe you need to remove code, instead of adding it twice.
    - 5y ago
nisa 5y ago
It's kind of ironic reading that from Martin Fowler that is for me the astronaut architecture goto person :). I have huge respect for this work but I guess a lot of technical debt is probably caused by implementing these complicated pattern - add some AbstractSingletonProxyFactoryBean joke here.
- johndfsgdgdfg 5y ago
  I pretty much lost respect for him when he started advocating short methods. From [1]: > In my Ruby code, half of my methods are just one or two lines long. 93% are under 10. Are there professional engineers out there who reads this tweet and thinks striving for one or two lines methods is a good idea? I really don't understand how does this person have so much fame or so much authority on architectures? What exactly are his accomplishments other than selling books and seminars? Can someone please explain how come Martin Fowler is so revered among developers? [1] https://twitter.com/martinfowler/status/893100444507144192 https://twitter.com/martinfowler/status/893100444507144192
  - majormajor 5y ago
    Have you read his books or just his tweets? 1-line methods is taking things to an extreme (though you can write a lot of logic into a single line in Ruby, so maybe it's not as crazy as it would be in C...) but I found the discussion in his refactoring book about reorganizing methods and naming things very illuminating. It's an idea so simple it sounds stupid sometimes to try to explain to people, and yet, I never stop seeing new code that could be improved by something as simple as methods with accurate names. E.g. I've seen a lot of stuff like: ``` // This does X [some obtuse nasty inline regex or five-layers-deep nested object call or otherwise crazy individual line of code] ``` That maybe eventually gets detached from that comment line and now there's just some nasty line that nobody on the team understands anymore that can't as-is be easily tested in isolation from a bunch of other stuff. A perfect opportunity for a one-line method, that can have a descriptive name and can have its own specific tests. And yeah, again, that's the extreme case, but most codebases have tons of opportunities for 5-10 line methods being extracted with helpful names. If you find yourself writing a comment to describe a block of code, maybe make that comment your method name instead. And sometimes you try it, and realize "wow, it's hard to extract these methods without an insane amount of input params and return values for each bit" and maybe that's an important thing to realize about the code you're looking at anyway. ;)
thrower123 5y ago
I'm not sure I've ever seen it happen except by declaring bankruptcy.
- Silhouette 5y ago
  It can happen. Sometimes it even happens on big projects that are deep in debt. But it only ever happens when the hands-on people get to spend significant time on improving what is happening behind the scenes. That might mean 20% or 50% of their time, not the 2% or 5% that many get. If the hands-off people calling the shots aren't willing to make that commitment then a heavily indebted organisation's fate is already sealed.
snvzz 5y ago
While there are laws in place to prevent usury, they do not apply to the compounding interest that will be accrued where there is technical debt.
- thunderrabbit 5y ago
  Nicely said!
rq1 5y ago
There’s no such a thing as technical debt. There’s sometimes bad code that one resolves by redesigning some part of it with eventually some glue code with the old system, documenting it and making a presentation for everyone on how should the new stuff be written, and distribute work for a slow migration of the old systems by the different parties. I’ve seen also some systems designed to solve problem X while the company or industry moved on to problem Y. Again, act like a virus, infect the system with your brand new solution, glue it or bind somehow with the old system and let it spread. The only mistake that you can do is to engage all of your resources to undertake a full redesign and rewrite everything from scratch. And for processes or algorithms that don’t scale, it’s not a debt because you never really made the investment.
deleted 5y ago
[deleted]
vs2 5y ago
I am starting to believe that software has a shelf life. Some of its fresh fruit and milk and some of it is canned beans that will survive for a long time. An answer to technical debt is throw out software
- arvinsim 5y ago
  That's the concept of Software Rot[1], isn't it? [1] https://en.wikipedia.org/wiki/Software_rot https://en.wikipedia.org/wiki/Software_rot
adityaathalye 5y ago
Over time, I've come to believe discussions around "Technical Debt" do not sufficiently examine the nature of the risk of the underlying challenge. The framing also skews and pigeonholes the responsibility part of addressing things. I've tried to articulate this (a bit tongue-in-cheek) here: https://www.evalapply.org/posts/software-debt/ https://www.evalapply.org/posts/software-debt/ In short, I feel a re-scoping in terms of "Software Debt" is warranted. And a re-casting of the risk of this debt in terms of the rocket equation, and opaque financial derivatives of the kind made infamous in 2007/08.
ochronus 5y ago
How we talk about tech debt, how we argue about its importance and how different functions in a team (tech and non-tech) can get to a common ground is usually the most important and many times the most overlooked part of this. Teams tend to fluctuate between "everything is important" and "our PM never lets us do any tech debt relief work". Shameless plug: https://leadership.garden/tips-on-prioritizing-tech-debt/ https://leadership.garden/tips-on-prioritizing-tech-debt/

81 points by nilsandrey 5y ago

While the article delivers nice explanations for what kind of technical dept exist, it stays very generic and hand-wavy for the solutions. Bringing "microservices" into the room is definitely not helpful. Ownership and setting a quality bar..., sure but how does that look like? As I developer I maybe have an idea but I also need to sell that to management. As manager I have an idea too but I need to convince my developers to strive for quality and sustainability. Sometimes I wish these articles would just state: Stop sprinting Also: document your decisions! If you have to write down and justify your (prudent) technical dept, you maybe catch some stuff before it's written in code. It also makes sure more people are aware of it. Additionally, it sometimes prevents CV driven development, which imho is a big problem in tech. Overall, documentation is a very underused tool. Finally: teach everyone (especially marketing) that software development is expensive, so everybody thinks twice before wishing for nice to have features done quick.

sirwhinesalot 5y ago
Could not agree more. The solution to tech debt is the one nobody wants to hear: Slow down! Steve Jobs' presentation of Snow Leopard should be mandatory viewing for every manager. "No new features" to a standing ovation. Customers actually like stable, responsive, and efficient tools, who would have thought? EDIT: > Bringing "microservices" into the room is definitely not helpful It's a pretty good way to increase technical debt. The microservices themselves might become small enough that it is easy to refactor some at a time, but then you have the actual deployment and communication infrastructure to contend with. And if you get that architecture wrong, oh boy you'll be begging to go back to a monolith in a day.
- peakaboo 5y ago
  This happens constantly, the entire tech industry runs in whatever direction Google in particular is going. First it was Hadoop and all the pain that came with that, and now it's microservices and kubernetes and all the shit that brings into our tech stacks. Stop sprinting is good but also : stop following Google. You are not Google. You do not have the needs of Google. Just stop it. Pick the simplest tech stack you can find. This gives 100x more time to your developers to work on company solutions and not fighting technical complexity.
  - floydian10 5y ago
    > now it's microservices and kubernetes and all the shit that brings into our tech stacks. For all the talk about "no silver bullet", there's a staggering amount of folks who keep falling for it.
  - nwmcsween 5y ago
    The problem is you eventually need the things k8s offers and you end up implementing part of k8s, badly. I've seen bigish places that state "we aren't Google" as an argument to not use k8s, containers, etc but don't consider that their tech stacks are a Hodge Podge of bespoke glue, a mass of technical debt and a bus factor of generally 1 or 2.
    - sirwhinesalot 5y ago
      As someone who works on a hodge podge of bespoke glue, a mass of technical debt, a bus factor of 1, and a docker swarm setup, I don't really see how k8s would help ;)
    - majormajor 5y ago
      The question they should be asking isn't "is this tech stack perfect or a mess" it's "is this actively preventing, or about to prevent, us from meeting our uptime and cost and development goals"? The idea that a shop that built a messy system will suddenly build a non-messy system just if they pick up a new set of tools - that they don't have practice with anyway! - is exactly the silver-bullet fallacy. The system turned out messy because it's complicated, switching to a very complicated tool doesn't take away the complexity, it just changes the way you manage it. The last couple Kubernetes shops I worked at were that exact sort of hodge podge of custom glue with high tech debt and low bus factor. Just even doing something "simple" like "ssh into the box and poke around" when the two wizards are out suddenly has a huge learning curve. ;) So then you get into discussions of "oh you should've been using managed kube" or "oh, don't use TF -> helm -> kube, use [other way] of managing it" or blah blah. After you fuck it up a few time you might have enough useful experience so that you can build it well next time... just pray that by then we're still using the same tools. :D
- tonyjstark 5y ago
  Snow Leopard is exactly what I had in mind when writing the comment. I remember watching the keynote and my own excitement about introducing no new features. Additionally to managers watching that presentation, software architects should mandatory have to work as normal developers in every project they designed for a a few months. Best, if it would be around 2 years after they came up with the architecture. If you don't taste what you cook, how can you learn? I fully agree on your points with microservices.
- jamesfinlayson 5y ago
  > It's a pretty good way to increase technical debt. The microservices themselves might become small enough that it is easy to refactor some at a time, but then you have the actual deployment and communication infrastructure to contend with. And if you get that architecture wrong, oh boy you'll be begging to go back to a monolith in a day. I remember at a previous job, the monolith was drowning in technical debt. Someone decided the solution was Go microservices. Fast-forward 18 months and 95% of the functionality is still in the monolith, but there are now 25 microservices, and no environment (except production) where you can test everything together.
  - mattbillenstein 5y ago
    Coinbase?
  - KronisLV 5y ago
    > I remember at a previous job, the monolith was drowning in technical debt. Someone decided the solution was Go microservices. Fast-forward 18 months and 95% of the functionality is still in the monolith, but there are now 25 microservices, and no environment (except production) where you can test everything together. I have the opposite anecdote. Currently working on a monolith that's been around for 5-7 years, huge enterprise Java mess, like many others in the industry. The clients decided that they'd like to upgrade to JDK 11, newer frameworks, all of that shiny stuff. So for the past 4 months i've essentially been pulling my hair out and trying to rewrite significant parts of it all. When you have a monolith, you cannot upgrade the entire system if some parts of it break - even if i have, say, 200 dependencies but 10 break, i cannot move forwards with the updates and as a consequence am stuck with running on JDK 8 or even outdated frameworks. And, of course, you cannot extract those parts of the system out either because you'll immediately be hounded by developers who aren't welcoming of change and will find nitpicky stuff to tear both your arguments and efforts apart, actively sabotaging any potential successful outcome (potentially exaggerating here, but many do not enjoy change). Alas, there is probably some sweet spot to work towards from day 1. Not going crazy with microservices, especially due to how people interpret the "micro" part (e.g. service per person vs service per team, what the total count should be, domain modeling etc.), but not sticking to a single large monolith either. I think that sooner or later the industry will try grouping code into services based on the "type" of functionality - the weird PDF export and reporting logic will live in service A, other attachment upload/download logic in service B, the web API in service C, and the old legacy server side rendered UI in service D. That way, at least your efforts to update the web framework and JDK for it wouldn't be usurped by the PDF library not liking it. Then again, i've seen front end applications baked into back end applications instead of separate back end/front end deployments far too often, so i'm not hopeful about anyone genuinely exploring that approach anytime soon. Alternatively, i've actually written about modular monoliths before, in my article "Moduliths: because we need to scale, but we also cannot afford microservices": https://blog.kronis.dev/articles/modulith-because-we-need-to-scale-but-we-also-cannot-afford-micro-services https://blog.kronis.dev/articles/modulith-because-we-need-to...
- fivre 5y ago
  > Customers actually like stable, responsive, and efficient tools, who would have thought? _Existing_ customers like these things (and they aren't wrong for liking these things). New business comes from the potential customers who weren't enticed by the existing feature set, robust or otherwise. You bring them in by adding new features. The retain/new business priority is often heavily weighted in favor of the latter. Retaining existing customers stuck with a crappy product ain't that hard between sunk cost/lock-in effects and the evergreen insulation of people with purchasing authority from the day-to-day pain inflicted by their purchasing decisions. A couple fancy steak dinners for middle management effectively papers over the cost of driving a department of ops engineers to cirrhosis several times over.
  - sirwhinesalot 5y ago
    You're absolutely right, and it makes me sad :(
- mattbillenstein 5y ago
  Slowing down is really being able to say "no" to features for awhile while you re-architect the codebase - so you're delivering stuff at the same pace, but that stuff is not product-facing. I've been through this slog - sometimes it requires fixing what's there and other times, a rewrite. People hate rewrites, but it really is the best way forward in a lot of cases if done correctly.
hinkley 5y ago
If only the author had written a book about how to alter crappy code to make it better. Then maybe he could give us a plan!
ac50hz 5y ago
+10 This is my experience with many different systems. I’ve found that mentoring and personal development identification techniques for what to learn, and when, can be helpful. Inviting a developer to be part of the decisions made regarding their future may seem obvious, but in practice it’s often not done… And documentation… I’m known as “Just write it down,” but there is usually significant pushback… from all parties.
noir_lord 5y ago
> hand-wavy for the solutions This is Fowler (and Uncle Bob's) stock in trade tbh. Generic good advice that sounds plausible in a sane world. Without ever acknowledging that we actually don't live in that world.

keithalewis 5y ago

Techical debt is primarily about managing complexity, the bane of software engineering. Do not underestimate the value of having a coherent _theory_ about the problem being solved. Something everyone on the team understands and that can be taught to new hires. If you give a programmer a keyboard and a paycheck they will press on keys all day long.

bokohut 5y ago
And if complexity can be designed out from day zero with a clear and concise foundational development model to follow then the technical debt can be greatly reduced as well. This of course conflicts with the global rush into tech to build something as fast as possible to get to revenue and not investing the time proactivity to build for the long game. Planning and control are my two points that get extreme focus in designing that foundation as the world comes to learn the importance of these items impacting cybersecurity, fairly important now-a-days it seems, and so much more. If you know something works then no need to reinvent it every time.
- hinkley 5y ago
  Designed out on day zero is the siren song of waterfall. Getting it right the first time is a very hard game to win. It’s best to save some of your energy for the times that really count. It’s always interesting to me when coworkers exclaim that doing the right thing is too hard. Reminds me of myself at age nine trying to get out of chores. More seriously though, “if it hurts stop doing it” is how dumb animals think. Pain is information. Ignoring it is dumb. Almost as dumb as giving up is. Just last week I was having a hell of a time getting some code to work. Running into a wall. Okay fine, I’ll write more tests. Still struggling. Oh hey, you know what would make this way easier? If I rearranged this code in the manner I thought about this morning but decided to not work on until tomorrow. If eating the code is difficult, there’s a point of very quickly diminishing returns where adding more logic to the tests is making things worse, and you should think about whether The code is too complicated to test. Maybe you need to remove code, instead of adding it twice.
  - 5y ago

nisa 5y ago

It's kind of ironic reading that from Martin Fowler that is for me the astronaut architecture goto person :). I have huge respect for this work but I guess a lot of technical debt is probably caused by implementing these complicated pattern - add some AbstractSingletonProxyFactoryBean joke here.

johndfsgdgdfg 5y ago
I pretty much lost respect for him when he started advocating short methods. From [1]: > In my Ruby code, half of my methods are just one or two lines long. 93% are under 10. Are there professional engineers out there who reads this tweet and thinks striving for one or two lines methods is a good idea? I really don't understand how does this person have so much fame or so much authority on architectures? What exactly are his accomplishments other than selling books and seminars? Can someone please explain how come Martin Fowler is so revered among developers? [1] https://twitter.com/martinfowler/status/893100444507144192 https://twitter.com/martinfowler/status/893100444507144192
- majormajor 5y ago
  Have you read his books or just his tweets? 1-line methods is taking things to an extreme (though you can write a lot of logic into a single line in Ruby, so maybe it's not as crazy as it would be in C...) but I found the discussion in his refactoring book about reorganizing methods and naming things very illuminating. It's an idea so simple it sounds stupid sometimes to try to explain to people, and yet, I never stop seeing new code that could be improved by something as simple as methods with accurate names. E.g. I've seen a lot of stuff like: ``` // This does X [some obtuse nasty inline regex or five-layers-deep nested object call or otherwise crazy individual line of code] ``` That maybe eventually gets detached from that comment line and now there's just some nasty line that nobody on the team understands anymore that can't as-is be easily tested in isolation from a bunch of other stuff. A perfect opportunity for a one-line method, that can have a descriptive name and can have its own specific tests. And yeah, again, that's the extreme case, but most codebases have tons of opportunities for 5-10 line methods being extracted with helpful names. If you find yourself writing a comment to describe a block of code, maybe make that comment your method name instead. And sometimes you try it, and realize "wow, it's hard to extract these methods without an insane amount of input params and return values for each bit" and maybe that's an important thing to realize about the code you're looking at anyway. ;)

thrower123 5y ago

I'm not sure I've ever seen it happen except by declaring bankruptcy.

Silhouette 5y ago
It can happen. Sometimes it even happens on big projects that are deep in debt. But it only ever happens when the hands-on people get to spend significant time on improving what is happening behind the scenes. That might mean 20% or 50% of their time, not the 2% or 5% that many get. If the hands-off people calling the shots aren't willing to make that commitment then a heavily indebted organisation's fate is already sealed.

snvzz 5y ago

While there are laws in place to prevent usury, they do not apply to the compounding interest that will be accrued where there is technical debt.

thunderrabbit 5y ago
Nicely said!

rq1 5y ago

There’s no such a thing as technical debt. There’s sometimes bad code that one resolves by redesigning some part of it with eventually some glue code with the old system, documenting it and making a presentation for everyone on how should the new stuff be written, and distribute work for a slow migration of the old systems by the different parties. I’ve seen also some systems designed to solve problem X while the company or industry moved on to problem Y. Again, act like a virus, infect the system with your brand new solution, glue it or bind somehow with the old system and let it spread. The only mistake that you can do is to engage all of your resources to undertake a full redesign and rewrite everything from scratch. And for processes or algorithms that don’t scale, it’s not a debt because you never really made the investment.

deleted 5y ago

[deleted]

vs2 5y ago

I am starting to believe that software has a shelf life. Some of its fresh fruit and milk and some of it is canned beans that will survive for a long time. An answer to technical debt is throw out software

arvinsim 5y ago
That's the concept of Software Rot[1], isn't it? [1] https://en.wikipedia.org/wiki/Software_rot https://en.wikipedia.org/wiki/Software_rot

adityaathalye 5y ago

Over time, I've come to believe discussions around "Technical Debt" do not sufficiently examine the nature of the risk of the underlying challenge. The framing also skews and pigeonholes the responsibility part of addressing things. I've tried to articulate this (a bit tongue-in-cheek) here: https://www.evalapply.org/posts/software-debt/ https://www.evalapply.org/posts/software-debt/ In short, I feel a re-scoping in terms of "Software Debt" is warranted. And a re-casting of the risk of this debt in terms of the rocket equation, and opaque financial derivatives of the kind made infamous in 2007/08.

ochronus 5y ago

How we talk about tech debt, how we argue about its importance and how different functions in a team (tech and non-tech) can get to a common ground is usually the most important and many times the most overlooked part of this. Teams tend to fluctuate between "everything is important" and "our PM never lets us do any tech debt relief work". Shameless plug: https://leadership.garden/tips-on-prioritizing-tech-debt/ https://leadership.garden/tips-on-prioritizing-tech-debt/