[deleted]
Technical Debt: How do you get out of the bottleneck?
31–40 of 49 posts
Re: Technical Debt: How do you get out of the bottleneck?
#32I 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
Re: Technical Debt: How do you get out of the bottleneck?
#33Earlier quoted context omitted.
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. Som…
Coinbase?
Re: Technical Debt: How do you get out of the bottleneck?
#34While 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…
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.
Re: Technical Debt: How do you get out of the bottleneck?
#35It'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…
Cargo cult programming at it's maximum expression.
M. Fowler, Uncle Bob, Kent Beck, GoF authors...
Any book or post by these people is always brought up as a must read. A must read to understand why you should *not follow cargo cults* and see with your own eyes how toxic and damaging these guys are to software engineering culture.
In one hand, I'd say these guys are absolutely revered among computer science students (their main target to sell their books) and developers who have been stuck in the OOP and design pattern rabbit hole for decades without evolving.
In the other hand, the criticism is more present that ever. It's ironic, because the criticism has even lead Uncle Bob to jump the wagon and start to sell Functional Programming in Clojure as a new super *secret formula* and *best practice for real engineers*.
Re: Technical Debt: How do you get out of the bottleneck?
#36It'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 there professional engineers out there who reads this tweet and thinks striving for one or two lines methods is a good idea?
Striving for the shortest possible methods (less than 10 lines is good) is a standard in Smalltalk. It's not a bad idea, at least, it's been shown to work over and over again over the last 50 years. Ruby takes a lot of inspiration from Smalltalk, although it lacks the biggest factor that made short methods work so well in Smalltalk: the interactive editing of the code as it runs.
Another example where a subroutine longer than a few lines is frowned upon is Forth. Also in that case, interactive editing is the main motivation, along with the fact that the amount of irrelevant bookkeeping grows linearly (or worse) with the subroutine length (unless you use local variables or the return stack, which are both hacks in Forth).
In any case, "professional engineers" who don't even know Smalltalk... No, I mean, the history and breadth of their field, probably should not be too judgemental about what works where, outside of their immediate expertise.
Re: Technical Debt: How do you get out of the bottleneck?
#37Earlier quoted context omitted.
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…
Cargo cult programming at it's maximum expression. M. Fowler, Uncle Bob, Kent Beck, GoF authors... Any book or post by these people is always brought up as a must read. A must read to understand why you should *not follow cargo cults* and see with your own eyes how toxic and damaging these guys are to software engineering culture. In one hand, I'd say these guys are absolutely revered among computer science students…
Any "musts" in Software Engineering that purport to be universal must be met with lots of skepticism.
Re: Technical Debt: How do you get out of the bottleneck?
#38I 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
That's the concept of Software Rot[1], isn't it?
Re: Technical Debt: How do you get out of the bottleneck?
#39Over 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/
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.
Re: Technical Debt: How do you get out of the bottleneck?
#40Earlier quoted context omitted.
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. Som…
> 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...