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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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".
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.
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
tonyjstark|4 years ago
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|4 years ago
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.
ac50hz|4 years ago
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|4 years ago
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.
hinkley|4 years ago
nisa|4 years ago
johndfsgdgdfg|4 years ago
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
Jtsummers|4 years ago
snvzz|4 years ago
thunderrabbit|4 years ago
keithalewis|4 years ago
bokohut|4 years ago
hinkley|4 years ago
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.
adityaathalye|4 years ago
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.
thrower123|4 years ago
Silhouette|4 years ago
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.
ochronus|4 years ago
Shameless plug: https://leadership.garden/tips-on-prioritizing-tech-debt/
rq1|4 years ago
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.
vs2|4 years ago
arvinsim|4 years ago
[1] https://en.wikipedia.org/wiki/Software_rot
unknown|4 years ago
[deleted]