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.
Nicely said!
Technical Debt: How do you get out of the bottleneck?
21–30 of 49 posts
Re: Technical Debt: How do you get out of the bottleneck?
#22Earlier 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…
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 sto…
Re: Technical Debt: How do you get out of the bottleneck?
#23Earlier 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…
Pick the simplest tech stack you can find.
There is a lot of merit in that argument.
It never ceases to amaze me how much effort we now spend on nothing but infrastructure and architecture. It's like the Cloud Way of "cattle not pets" and "infinite horizontal scalability" may no longer be questioned.
Meanwhile you could build almost anything in this space with little more than a rack of real servers, some respectable application code written in a fast language, and a bit of scripting and OSS for the glue.
Obviously that sort of environment wouldn't be sufficient for every modern, online-first application but how many years would it take to outgrow it? Many applications never reach that scale. The lucky few would be in a great position to expand from if their starting point was simple and transparent with minimal dependencies.
Re: Technical Debt: How do you get out of the bottleneck?
#24I'm not sure I've ever seen it happen except by declaring bankruptcy.
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.
Re: Technical Debt: How do you get out of the bottleneck?
#25While 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…
> 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.
Re: Technical Debt: How do you get out of the bottleneck?
#26While 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…
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!
Re: Technical Debt: How do you get out of the bottleneck?
#27Earlier 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…
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 sto…
> // This does X
> [some obtuse nasty inline regex or five-layers-deep nested object call or otherwise crazy individual line of code]
… which no longer does X
Re: Technical Debt: How do you get out of the bottleneck?
#28Techical 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.
Technical debt is about managing accidental complexity. But well-placed accidental complexity can make inherent complexity look much, much bigger than it really is.
Clearing debt can be a bit of a fishing expedition, but as long as enough of them have a payoff, it hardly matters if occasionally they come up goose eggs.
Re: Technical Debt: How do you get out of the bottleneck?
#29Techical 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 d…
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.
Re: Technical Debt: How do you get out of the bottleneck?
#30While 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…
+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.