Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Garbage collect your technical debt (2021)

ieeexplore.ieee.org

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Garbage collect your technical debt (2021)

#81

Post by wavemode »

zarathustreal wrote: post #72
anymouse123456 wrote: post #64

Wow, what a weird feeling. The authors of this article seem like super smart and experienced guys, but the article itself is introduced with incorrect statements in the very first two sentences and slides downhill from there. "There is a kind of design distortion that happens when a team chooses to build iteratively instead of looking at all of the requirements at once. Ward Cunningham coined the term technical debt…

I would argue that there is the option to look at all the requirements at once. The disconnect with your mental model is in the definition of the piece of software being designed. You’re considering all iterations to be the same piece of software, despite ostensibly having different sets of features and functionality (e.g the ones added over time). Consider the alternative perspective that each new feature actually m…

I don't think that perspective really holds up to practical scrutiny. The most common sources of tech debt in the real world are when new features are tacked onto existing software without integrating with them fully/smoothly.

As a relatable example, think about how the Control Panel in Windows still uses a 2000s-era UI, even as the Settings menu, and most of the rest of the OS, uses a new UI. The likely reason for this is that it was faster to tack on a new UI and leave the Control Panel as-is. It would've taken more time to refactor the Control Panel from the ground up to accomodate a new UI.

The end result is that there are now two separate settings interfaces, and there is probably some ongoing engineering effort required in maintaining both and keeping them coherent with one another. That's a classic example of tech debt - save time now, but it may cost you later.

But, by your definition, the old UI and the new UI are separate pieces of software, therefore there is no debt. How does that track?

Re: Garbage collect your technical debt (2021)

#82

Post by shepherdjerred »

teeray wrote: post #29
noisy_boy wrote: post #25

I do opportunistic collection - when I am working on a feature, and spot opportunities for a refactoring/cleanup in code that is more or less directly related to the code I'm touching, I will keep making small incremental changes and keep testing them until my feature is implemented and the cleanup is done as well. I also ensure to not make a breaking change while doing this e.g. no change to the user facing api sign…

I have done this in the past and it has worked well. On some teams though, I have been met with: “Why did you do this refactor with the feature? Can you pull the feature into another PR, then we’ll leave the refactor in the original PR to be merged at another time? (read: never)”

A refactor should, at the very least, be in another commit if not another PR.

The refactor being separate in a separate commit/PR makes your code easier to review.

> Why did you do this refactor with the feature?

This indicates that the team doesn't think the refactor is needed or it wasn't a priority for them.

Teams that push back probably have a different mindset than you. Some teams don't understand the negative impact of tech debt, others don't know how to prioritize it.

Re: Garbage collect your technical debt (2021)

#83

Post by shepherdjerred »

yarekt wrote: post #55
woodpanel wrote: post #44

Ctrl+F "@TODO"… or have your build pipeline keep track of Todos automatically. Also some IDE integrations keep track and provide quicklinks to lists of TODOs.

Curious. Got any recommendations for CI tooling that analyses todos? What sort of things that you’ve seen are possible

I read this interesting paper a year or two back about triggerable TODOs in Java: https://users.ece.utexas.edu/~gligoric/papers/NieETAL19TrigI...

Re: Garbage collect your technical debt (2021)

#84

Post by physicles »

benji-york wrote: post #50
physicles wrote: post #32

Earlier quoted context omitted.

I’m lucky that I don’t have a boss like this, but I’ve asked myself this question recently. I’ve been with the same company for almost eight years working on the same code base, which I and another dev greenfielded. I know it very, very well. I’m often dismayed at how long things seem to take these days compared to when we first started out. Am I getting slower? Lazier? So far, I’ve identified the following factors:…

I wish I had more than one upvote to give you for this post. > I’ve asked myself this question recently. I suspect both are true. There are real complexities that have grown around you and working in the same way on the same stuff for so long has caused you to habituate to a few inefficiencies. I suggest shaking up your world view a little and seeing what falls out. There are probably a few big gains you could make.…

Thanks, much appreciated! Any ideas how to kick start that shakeup? Hackathons on devops or proceeds stuff? Brainstorming? Consultants?

Re: Garbage collect your technical debt (2021)

#85

Post by marcus_holmes »

naasking wrote: post #71
marcus_holmes wrote: post #36

So, from my 30+years building software products, I have a couple of problems with this: - we don't choose iterative development as an alternative to waterfall because "waterfall is bad mmkay". When developing a new product, we don't know all the requirements. Part of the process of iterative development is discovering the requirements. Every waterfall project is secretly an iterative project because there's always a…

> Every waterfall project is secretly an iterative project because there's always a Phase 2 where the requirements get updated This is a false equivalence. Waterfall is iterative in requirements but not in code . Changing the requirements document is much, much simpler than changing the code to conform to new requirements. > The optimum amount of tech debt is not zero. Tech debt is a product of changing the product p…

If the requirements change, then so must the code. The code you wrote for phase 1 cannot (by definition) include the changes needed for phase 2. Especially because you don't discover the changes needed for phase 2 until partway through phase 1.

Writing code so that it can be easily changed to conform to new requirements is a trade-off, like everything. You will incur some cost to do this, probably longer dev times. In many cases this trade-off is not worth it.

And in my experience, shipping a new feature faster is always the goal. Dealing with the tech debt incurred is a tomorrow problem, and tomorrow we will have more funding/staff/time to deal with it than we do today. It's not always true, of course, but that's the attitude generally.

Re: Garbage collect your technical debt (2021)

#86

Post by igornadj »

Does anyone else get the feeling that how we deal with technical debt in software is fundamentally and critically misguided?

How a pot hole gets filled in isn't a technical challenge, its a political challenge.

Developers can talk about the _technical_ side of technical debt all day long, but its a) generally well understood already, and b) blowing in the wind. How technical debt is handled is fundamentally a political problem.

We may understand this at a glance, but the solution of "gain knowledge and bring it up at standup" is not only not getting us anywhere, it's deliberately misleading us into thinking its up to us individually to change the organisation. It's as silly as telling the labourer that part of their job is to lobby the city council to spend more time and resources on filling pot holes.

Discussions on technical debt should be within the bounds of how to identify organisations where technical debt is identified as a real issue from the top down, and a survival guide for working in organisations where it is not.

Re: Garbage collect your technical debt (2021)

#87

Post by benji-york »

physicles wrote: post #84
benji-york wrote: post #50

Earlier quoted context omitted.

I wish I had more than one upvote to give you for this post. > I’ve asked myself this question recently. I suspect both are true. There are real complexities that have grown around you and working in the same way on the same stuff for so long has caused you to habituate to a few inefficiencies. I suggest shaking up your world view a little and seeing what falls out. There are probably a few big gains you could make.…

Thanks, much appreciated! Any ideas how to kick start that shakeup? Hackathons on devops or proceeds stuff? Brainstorming? Consultants?

I would approach it—at least initially—as a mental exercise. What are your assumptions about the role, the code, the product? How could you (in)validate those. What would it look like to take each thing you think you know and invert them one at a time? What if things that you think are bad are actually good? What if things you think are fast could be twice as fast? Etc.

Re: Garbage collect your technical debt (2021)

#88

Post by anymouse123456 »

zarathustreal wrote: post #72
anymouse123456 wrote: post #64

Wow, what a weird feeling. The authors of this article seem like super smart and experienced guys, but the article itself is introduced with incorrect statements in the very first two sentences and slides downhill from there. "There is a kind of design distortion that happens when a team chooses to build iteratively instead of looking at all of the requirements at once. Ward Cunningham coined the term technical debt…

I would argue that there is the option to look at all the requirements at once. The disconnect with your mental model is in the definition of the piece of software being designed. You’re considering all iterations to be the same piece of software, despite ostensibly having different sets of features and functionality (e.g the ones added over time). Consider the alternative perspective that each new feature actually m…

There are some bits of software that are simple enough to describe first and then implement, but just about any software that has more than one person working on it is more complex than that (IME), and for those cases, one might as well just implement it anyway.

There are varying degrees to which a team or business may invest in collecting and negotiating requirements before starting development, and there is obviously some amount of this work that is essential and valuable.

That said, as this planning investment grows beyond some reasonable point, and moves deeper into technical details, it will be composed of more waste and this waste will only become apparent as the people executing discover the real technical and product requirements.

The technical debt we're discussing will become an option immediately as the engineering work begins, and it's up to the team to decide how much, if any debt they are interested in taking on at whatever point in time.

I'm not convinced that it's helpful to conceive of the thing we're all working on and becoming more and more intimately familiar with as a new thing over some randomly selected interval.

There is no reality in which we can fully design or specify everything up front. If the specification were comprehensive, it would be the solution.

Re: Garbage collect your technical debt (2021)

#89

Post by caseyohara »

marcus_holmes wrote: post #37
caseyohara wrote: post #10

> Building software iteratively leads inevitably to tech debt because we choose to deliver systems before we have looked at all the requirements. Not knowing what’s next distorts our designs, and that distortion is the tech debt. This article frames technical debt as something that happens passively because you can't know future requirements. That's sometimes true, of course, but in my experience the majority of tech…

How would you recommend implementing a feature that might get rolled back or fundamentally changed depending on user reaction to it? Doing it the "right" way incur a lot of up-front expense that will be wasted if the feature is rolled back.

This is a perfect example of when deliberately taking on technical debt is the smart thing to do. You build the feature the "fast way", deliberately incurring technical debt to get faster feedback on the feature. If the feature doesn't work out, you can remove it quickly. If it does work out, then you can be confident that building it the "right way" is now worth the investment.

Technical debt is just like regular financial debt in that it can be a powerful tool when leveraged correctly.

Re: Garbage collect your technical debt (2021)

#90

Post by marcus_holmes »

caseyohara wrote: post #89
marcus_holmes wrote: post #37

Earlier quoted context omitted.

How would you recommend implementing a feature that might get rolled back or fundamentally changed depending on user reaction to it? Doing it the "right" way incur a lot of up-front expense that will be wasted if the feature is rolled back.

This is a perfect example of when deliberately taking on technical debt is the smart thing to do. You build the feature the "fast way", deliberately incurring technical debt to get faster feedback on the feature. If the feature doesn't work out, you can remove it quickly. If it does work out, then you can be confident that building it the "right way" is now worth the investment. Technical debt is just like regular fi…

This. 100% agree
Post reply on HN