Comment by SkyPuncher | Hacker News Reader

Comment by SkyPuncher | Hacker News Reader

I'm being a bit blunt here. It's easy to say Technical Debt will ruin your software when you pick a contrived thing and label it as Technical Debt.

> John knew his code had a few bugs. But nearing the deadline, another project appeared and it took a lot of John’s time, so he couldn’t go back and fix the problems.

This is a problem, but this is not inherently technical debt. That's just delivering a bad/incomplete feature (Not necessarily John's fault if he's been asked to make changes). Code with Technical debt works or mostly works, but relies on non-maintainable or less ideal than patterns.

Simplified example. Adding a "Cancel" Button to a form. This button involves adding a new "secondary" class style to the button.

* Technical Debt - Button is in place. Works correctly. Instead of a <Button> component and tweaking it to handle the new "secondary" class. John simply copies and pastes the <Button> code directly into the implementation.

* Bug/Bad Feature - John references the button correctly, but fails to handle certain state resets properly when the form is cancelled.

-----

The prior is technical debt because it works correctly, but doesn't follow a good pattern or does something unexpected (refactoring that button will be much, much harder). The latter is likely just bad code.

The case where the latter is not bad code is if the company has made an intentional decision to not handle cancel edge cases. Even here, I would argue that is product debt - not technical debt.

----

Every software product in the world has debt. Just like every software product in the world has bugs. You need to account for your debt as you grow. Otherwise it will eat you.

There's a grey area though, where you properly define a new style (yay) at the time the first Cancel button is created, but then down the road you find yourself with a whole bunch of new styles for things, and it turns out over time that the styles are maybe repetitious or subtly inconsistent or whatever. The debt has become the reality that the initial abstraction ("all our buttons are the same") hasn't kept pace with the needs of the product as it has iterated forward. Paying down the debt is creating new abstractions and updating all the buttons to be using them.

The worst case scenario is probably partial paydowns, where the abstractions get changed but some of the non-aligned stuff remains and so that you end up with a jumble. Especially combined with inadequate documentation (or a culture of inadequate documentation, where people don't even look because they don't expect it to be there), the old practices can end up being cargo culted forward even when someone attempted to create a better way.

On a slight tangent, my team had very good results when we finally brought a style guide online. Our org was big enough that people would be working on pages without context for the bigger design themes (especially related to sales/marketing). We required any UI variations to be added to the style guide, and we required a minor justification to add styles. This added just enough friction that a lot of the unintended variation went away, and a lot of the variation just to be different became explicit so discussions about the design could be more deliberate.

How did you enforce this style guide, e.g. to make sure that sales cannot simply write a proposal in Tahoma instead of your company font or marketing publishes a newsletter in Arial using underlined words (gasp)?

A couple of years ago I had to spend a considerable amount of time PoC'ing platforms and tools claiming to solve this issue and I remember there were virtually none that did this on-prem using established Office programs, without a four to five figure investment. The organisation in question ended up using password-protected Word files with forms (a royal pain). Before that, they had been using Excel files (apparently it's easier there to lock parts of the sheet you don't want users to mess with) but this was an even bigger pain as Excel still has this decade-old bug even in its latest version which distort graphics when row height is changed...).

Long story short, I'd be curious how you solved this and what software you used.

Mostly we enforced it adhoc. It helped that the whole design team was pushing for print standards at the same time.

It ended up being a bullet point that needed to be talked about during sprint planning. It helped that designers were part of some of these meetings. If our company had been bigger it would have certainly been more challenging.

Mostly we tried to make it part of the culture that we stick to what’s in the style guide. And anything that deviates had a task of adding it to the style guide.

I have to say, that I wasn’t completely on board for a long time, since I was sure company culture would make it hard to succeed. We had a champion who got us about 90% of the way there before leaving. But there was enough momentum that another dev managed to bring together the right personalities and solidify the mechanics of dealing with the style guide that it was a no brainer to make it part of the work flow.

We used git to store the html and css examples. Made it trivial to copy. And since devs controlled the repo, devs controlled the pull requests as well, and required review just like other PR. It helped that the designers we had/hired were willing to deal with git, even if they had low tech knowledge.

I’m not at that job anymore, so I don’t know how long before entropy wins. It’s the type of thing you have to keep tending for it to continue to be useful. But enough process was in place that it will likely continue to be useful for them for several years at least.

I would argue copy/pasted code is usually not technical debt because it's very isolated and easy to change, and it's cheap to consolidate it later. Crappy abstractions are a way bigger source of technical debt than repeating yourself IME. It's a lot easier to create a new abstraction than modify an existing one, so you generally want to wait as long as possible.

A single copy and paste isn't likely an issue. I've worked in code bases where that pattern ends up happening in dozens or hundreds of places - all with slightly different style/layouts. It becomes a night mare to change anything consistently across the code base because it's done differently in every place.

Copy/pasted code becomes technical debt at scale, especially if there's an unknown error in the original. Now you have 10s or 100s of variants out there, each individually tweaked and so not readily identifiable as true copy/paste repetition, all containing some variant of this subtle bug. You find out about for interface A, and fix interface A. Maybe you remember that B-C were copy/pasted versions of A and check them out and correct it there. But D-Z were all copies made by others, following your example, and you miss them.

It's not scalable, and produces severe consequences when used without care (which is most of the time, it seems).

Copy-paste is not a tech debt, but just bad practice. Bad practices can increase tech debt.

I think you are being downvoted for the first part of your first sentence, with which I also somewhat disagree: copy/paste usually creates technical debt and even though each pair is easy to fix, with time they almost always diverge and are forgotten about. Which is bad.

But I strongly agree with your second part: bad abstractions are a much bigger source of technical debt. Abstractions that do not match the problem lead to convoluted solutions, reduced functionality and are very hard to break out of with incremental fixes.

I think that's why I'm being downvoted too, but frankly if the codebase is so bad that something is being copy/pasted hundreds of times to the point of unmaintainability, the abstractions that same team would build would probably also be disastrous, and much harder to deal with. Is that preferable?

But tbh, I'm skeptical of the premise to begin with. It's still easier to gradually consolidate 100 slightly different uses of a pattern than blindly create an abstraction that adequately covers those 100 uses. If your team is useless, it's better that their code be fragmented and atomic anyway, because big mistakes are inevitable. You don't want to make it hard to touch those mistakes. You want that code to be uncoupled & disposable.

But at that point the argument is getting pretty abstract. Depends on the specific codebase.

If code problems exist because someone made a strategic decision to prioritize a different raft of work, then it's tech debt.

If it was a tactical failure by John, then we just call that Tuesday.

It seems like your definition of technical debt is whenever anything is not completed (to your satisfaction), which seems a bit broad. I look at technical debt as the results of deliberate (architecture, design, or prioritization) decisions which have adverse impacts on maintainability.

I don't think there is so much of a difference between the deliberate decision and the accidental implementation of an incomplete or broken feature.

I have written software with tests and without. The latter start like prototypes and become quite useful over time. At first, everything looked good and there where just very few minor bugs which could be fixed easily. But over time, there appeared more edge cases which cannot be tracked down. As there are no tests, there are no specific definitions of what each part of the software is supposed to do. Yes, there is a big picture of how everything should work together, but obviously it doesn't catch every edge case. The problem is, that as a developer I can't act as effectively on my code anymore, because I took some shortcuts in the past.

On the other hand, there are other projects where I have test suits and where I can be totally confident, that everything has a well defined spec of what it should do and where I can't break something accidentally without noticing it.

So in the end it doesn't matter if your shortcuts have been made deliberately (most of the time it is a mix anyway). What matters is that due to the shortcuts you can't act as effectively on your code anymore.

> where I have test suits and where I can be totally confident, that everything has a well defined spec of what it should do and where I can't break something accidentally without noticing it

I'm often in the middle. Where I have tests, they're not always (or rarely) the result of a "well defined spec". But... the tests do reference whatever the understanding of XYZ was at that time. That's often as well-defined as I can get. Clients will come back months later and say "this is broken". Well, no it's not. The tests work just fine. "No, that's wrong, it's not supposed to work that way". Well.. there's a test with notes indicating "do ABC then XYZ" and the test ensures that's working based on what was known/agreed on at that time. That's often not the same as "well defined" by a long shot.

Bugs can also be technical debt, but then it has to be that people make a conscious decision that the bugs are not that important - like John says this will have a problem if people do X and the decision is made that X is an edge case that won't happen and John should work on something important.

The point of the post gets to the need to account for the debt and handle it. I think you're in agreement. And to watch out for reckless debt- it gets you into more trouble than it's worth, by definition.

The subject has been written about many times. This is a pretty good summarization of it.

Not called out: * Reckless debt is misfeasance on the part of developers. * "Prudent" debt is often avoidable- arbitrary deadlines are arbitrary. Management may believe that enterprise data models are as malleable as CSS. So "reckless" needs to be applicable to management as well.

I'm swimming in many years' accumulation of both reckless debt and reckless mgt. The deliberately considered debt I can handle.

I know your example is contrived but its amazing how complex we make the web

<input type="reset" value="Cancel">

I think the technical debt in your example is called CSS.

notice the "deadline" there...so the must be magic to hit deadline and no technical debt?

Reply on news.ycombinator.com