
Technical debt and tacking into the wind (2013) - Tomte
https://flak.tedunangst.com/post/technical-debt-and-tacking-into-the-wind
======
ehnto
I have worked on many projects where pragmatism is the only way forward,
rather than a rewrite. Often the software focused answer is a rewrite of the
platform, but in the context of the business the right answer is often deep
understanding and maintenance.

Legacy software at first glance can seem unruly and hard to understand which
gives devs a kneejerk reaction to rewrite it. But make sure you give your
developers enough time to sit down with the code and understand it. Given some
time to really grok the platform's idioms often you can empathize with the
previous devs work and figure out how to work within their framework.

You have to take the risk of refactoring into account as well. There is no
guarantee you'll end up with better software, rather than just different
software. You could end up throwing away years of edge case handling and
feature development just so the core product runs on some new technology the
new team is familiar with.

~~~
yodsanklai
> But make sure you give your developers enough time to sit down with the code
> and understand it

It means that all future developers will have to spend a lot of time to
understand complex code that could be simpler. Also, when the code is very
complex, developers don't understand it fully, are hesitant and unhappy to
touch it. Every new feature becomes a challenge and can break something. You
need to rely on regression testing, but if you have tests, you may as well
refactor.

Another reason to refactor is that you want to give new developers the
satisfaction of "owning" part of the code. I read an article on software
engineering at Google saying that it was ok if some parts were rewritten over
and over.

> you can empathize with the previous devs work

Some devs are just bad and/or worked under strict time constraints. Code isn't
only a matter of taste. There are objective metrics that tell you if some code
can be improved.

~~~
ehnto
I'm not saying never refactor, but it's often done prematurely.

> It means that all future developers will have to spend a lot of time to
> understand complex code that could be simpler.

Code that's complex is often complex because the domain it's written for is
complex. I've heard it called incidental complexity. Could you write it more
simply? Potentially, but how sure are you that you're not about to get rid of
edge case handling or important features?

Tests only work if you're sure you understand the requirements well enough to
write the test. If you're at that point of understanding in the platform,
you've probably got a good idea of whether or not you should refactor.

> Another reason to refactor is that you want to give new developers the
> satisfaction of "owning" part of the code. I read an article on software
> engineering at Google saying that it was ok if some parts were rewritten
> over and over.

I think it's an attitude software learned while it's been flooded with easy
money, where the tangible cost of constantly throwing away code is never
really considered. Code is never considered an asset, but had you built a
tractor for a company they would definitely want to know why you want to build
a brand new tractor when the old one is working fine.

I have mostly worked in agency environments, and as such cost is always part
of the conversation. Often the only people who want the refactor is the
developers. It doesn't provide any value to the business. I often do advocate
for a refactor for some of the reasons you mention, but to get client buy in
you need to provide some real value, and when you have to think about that it
quickly discovers whether or not your refactor is frivolous.

~~~
Bartweiss
> _had you built a tractor for a company they would definitely want to know
> why you want to build a brand new tractor when the old one is working fine._

You're not wrong about the cost and the need to justify it, but I think you
might be underestimating how often this happens to physical products. Lists
like "the worst cars of all time" are full of needless reworks, frequently
driven by some executive's desire to fully "own" a product. I suspect the
biggest difference is just that as the cost of throwing away a working design
becomes more expensive and visible, the decision to do so slides higher up the
ranks.

------
gwbas1c
Honestly, I got so lost in the article that I'm not sure that I understand
what the point was.

IMO: It was always hard to justify preserving legacy ASP code once Microsoft
made the decision to end-of-life the entire ecosystem. Web development was
much newer than, and it was common to completely rewrite web applications in
the "language du jour."

IMO: It's also easy to justify "fun" projects like writing your own compiler.

Maybe I'm just being a "Monday Morning Quarterback," but would it have made
more sense to build an ASP -> ASP.Net converter as a standalone product?

~~~
sokoloff
Was part of an ASP->ASP.net conversion project whose project plan amounted to:
“load it up in Visual Studio, switch from ASP VB to VB.net, edit until all red
underlines are removed from the codebase. Should take 6-12 weeks.”

3 _years_ later, we were _almost_ done.

~~~
thrower123
I am dreading this transition when it becomes necessary for .NET Framework ->
.NET Core. On the surface, it's not too different, but then you look deeper,
and here is a dependency that changed completely between it's old Framework
version and the new Core one, there's a place that we're using Linq-to-SQL
instead of EF, there's an SDK that we use that is never going to be updated to
a Core version, etc.

~~~
gwbas1c
I believe it's coming in .Net 5, if I understand the roadmap correctly.

At least it's not a 100% new language skinned to look like the old one!

------
mekane8
If nothing else I appreciate the author linking to the Ward Cunningham post on
technical debt
[http://wiki.c2.com/?WardExplainsDebtMetaphor](http://wiki.c2.com/?WardExplainsDebtMetaphor)

I've heard so much talk about technical debt (and done plenty myself) over the
years and it almost always gets used to talk about improving the messy code of
the last idiot who worked on the project and didn't know what they're doing. I
really appreciated reading Ward's clarification that his original metaphor was
about going back and improving the code to show an improved understanding of
the problem. Assuming implicitly that the code is clean and well-written in
the first place. So now I don't know what to call the effort required to clean
up bad code written by inexperienced predecessors. Incompetence debt? Student
loans?

~~~
asdfman123
I feel like a lot of frustration towards technical debt is rooted in
projection. The code confuses you, and you feel dumb, but instead of accepting
your feelings you blame the guy who wrote it and assume they're dumb.

However, often people have good reasons for why they write the code they
write. For instance, maybe there are so many quirks and edge cases there's no
way to write clean code without creating a massive body of abstractions that
would just making development speed slower.

I'm all about clean code but as a senior developer I increasingly realize that
naturally, everything is a tradeoff. While you should be biased towards
neatness, sometimes writing pristine code just isn't worth the time or cost of
maintaining all those abstractions.

~~~
mekane8
Well said. And to be fair, I was talking mostly tongue-in-cheek about the
"idiot", etc. I've been that guy I'm sure.

I agree about the trade-offs, I've been there myself too.

------
mdtusz
Minor nit, but tacking is by definition, turning into/across the wind.

~~~
OrangeMango
Came here to write that. In modern sloop-rigged boats, I believe that the
general consensus is that tacking is less dangerous and gentler on your
equipment than jibing(gybing)/wearing.

In the tall-ship era of square-rigged vessels, wearing ship caused far less
wear-and-tear on your rigging and was something you did to be more cautious or
if your boat was far from a shipyard. Tacking through the wind was perhaps a
bit reckless and not something to be done unless chased by a privateer or you
were a warship in action.

------
searedsteak
If he wanted to say the boat in his analogy is going the wrong way, he failed.
Hugging the coastline to Nova Scotia is the shortest route from Savannah to
London: [http://www.gcmap.com/mapui?P=SAV-
LHR](http://www.gcmap.com/mapui?P=SAV-LHR)

------
arkanciscan
Idiom salad

