Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

martinfowler.com

Post reply on HN
Print view View original

11–20 of 49 posts

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

#11

Post by tonyjstark »

sirwhinesalot wrote: post #3
tonyjstark wrote: post #2

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 devel…

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 te…

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.

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

#12

Post by sirwhinesalot »

nwmcsween wrote: post #9
peakaboo wrote: post #6

Earlier quoted context omitted.

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…

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.

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 ;)

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

#13

Post by majormajor »

nwmcsween wrote: post #9
peakaboo wrote: post #6

Earlier quoted context omitted.

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…

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.

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

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

#14

Post by johndfsgdgdfg »

nisa wrote: post #5

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.

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

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

#15

Post by majormajor »

johndfsgdgdfg wrote: post #14
nisa wrote: post #5

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.

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…

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. ;)

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

#16

Post by Jtsummers »

nisa wrote: post #5

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.

Fowler isn't the author of the linked article. The authors are Tim Cochran and Carl Nygard, which you can see in the byline at the top.

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

#18

Post by jamesfinlayson »

sirwhinesalot wrote: post #3
tonyjstark wrote: post #2

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 devel…

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 te…

> 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.

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

#19

Post by toast0 »

johndfsgdgdfg wrote: post #14
nisa wrote: post #5

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.

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…

I haven't written any ruby, but I've seen very short methods used in Erlang and it can be useful. If you write one or two line methods, they're mostly to help name a concept and make the place they're called look more sensible.

Organizing all those small functions can be a challenge, though. Which is why I don't tend to have functions quite that small. But a lot of 10ish line functions tends to work ok. But then, Erlang doesn't have loops, and I don't like anonymous functions (unless they're so short and simple I don't expect to find them in a stack trace), so that tends to make things short by necessity.

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

#20

Post by rq1 »

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.

Post reply on HN