Technical Debt: How do you get out of the bottleneck?
martinfowler.com
Technical Debt: How do you get out of the bottleneck?
1–10 of 49 posts
Re: Technical Debt: How do you get out of the bottleneck?
#2While 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.
Re: Technical Debt: How do you get out of the bottleneck?
#3While 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 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.
Re: Technical Debt: How do you get out of the bottleneck?
#4Techical 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.
Re: Technical Debt: How do you get out of the bottleneck?
#5It'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.
Re: Technical Debt: How do you get out of the bottleneck?
#6While 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…
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.
Re: Technical Debt: How do you get out of the bottleneck?
#7I'm not sure I've ever seen it happen except by declaring bankruptcy.
Re: Technical Debt: How do you get out of the bottleneck?
#8Earlier 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…
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…
> 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.
Re: Technical Debt: How do you get out of the bottleneck?
#9Earlier 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…
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.
Re: Technical Debt: How do you get out of the bottleneck?
#10Techical 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.
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.