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

A Field Study on Technical Debt

blog.sei.cmu.edu

Post reply on HN
Print view View original

41–50 of 81 posts

Re: A Field Study on Technical Debt

#41

Post by dasil003 »

wellpast wrote: post #17

There are some grievances in codebases that do not come with a huge expense. For example, duplicated code. For another example, overly verbose code. I've seen a lot of new codebases and these are minor nuisances and are pretty easy (i.e., take little time) to cope with. I don't classify these as technical debt because if they cost anything it's always so little. What costs the most is architecturally unsound code. It…

> When a developer says 'It will take too long to do the right thing,' (i.e., build architecturally sound code) he/she is saying, 'I don't have the skillset.'

I'll be charitable and say this may be the case part of the time. But as a general argument it is bollocks. In the vast majority of production systems that survive for any amount of time there will be requirements changes, and sooner or later an engineer will face a choice of shoehorning an attribute in somewhere it doesn't fit naturally, versus refactoring to more appropriately model the new business universe. Saying that this won't happen if your skills are sufficient is a no-true-scotsman argument—it's all tradeoffs, and no matter how good you are at anticipating change, sooner or later even the best architect will be blindsided by some out-of-the-blue business requirement.

Re: A Field Study on Technical Debt

#42

Post by tracker1 »

mikekchar wrote: post #38
tbrownaw wrote: post #27

Earlier quoted context omitted.

The reason I bring this up is I am surprised that architectural choice is overwhelmingly the top technical debt concern. That doesn't seem right. I would expect it to be poor code due to time constraints. 1. The system grew alongside the devs' understanding of the problem space. There was never time to change decisions that were later found to be not the best (and the older such a decision is, the harder it is to fix…

The thing that is very frustrating in the "There was never time to change decisions..." bit is that there often is time. If you are curious about what I mean, I invite you to try a little experiment. For a few weeks (2-4 should be sufficient) tell people, "If you see something wrong with the design, refactor it as soon as you see it. If you need some extra time on your story to compensate for that work, just bring it…

As a developer I've had some very good and very bad experiences... usually centered around two issues.. 1. I am not a morning person and am consistently late, I get work done, but not at 8/9am on the dot. And, 2. because I will take the time to understand what I am working on... this usually results in some refactoring and generally less code in the end. I once saved enough code in size to include lodash, and eventemitter into the client side of a project, by refactoring out a piece using those two libraries. I was of course chastised because it took longer than expected. I left when the writing on the wall was I would be fired anyway... That was over a year ago, and my understanding is the project I was working on with a 3 month delivery time still isn't done because no effort was made to resolve technical debt and they kept throwing more people/teams at it.

Re: A Field Study on Technical Debt

#43

Post by [deleted] »

Joky wrote: post #26
pjungwir wrote: post #11

Earlier quoted context omitted.

As a first-year programmer a project manager said to me, "I've never heard a programmer praise another's code. It's always, 'This is crap!'" So I always try to be slow to criticize. There is a lot of crap, but things might not be as simple as you think. I really believe we should take more time to read and understand before we write. Or think about G.K. Chesterton's fence: https://en.wikipedia.org/wiki/Wikipedia:Ches…

Oh no, I always get rid of stuff I don't know why it's there. Because if it does not break when I run "make check", it's not covered by the testing and it shouldn't have been there in the first place anyway. And if it had a use for someone, but nobody knows, removing it is also a very efficient way to figure out :)

[deleted]

Re: A Field Study on Technical Debt

#44

Post by tracker1 »

gfosco wrote: post #9
stevecalifornia wrote: post #3

I have never worked in an environment where new employees didn't show up and declare that the existing infrastructure sucks. Knowing this, I caught myself doing the same thing. Reflecting on it, for me it was a coping mechanism. I was overwhelmed by all the new things and didn't understand why this was setup that way, etc. The reason I bring this up is I am surprised that architectural choice is overwhelmingly the to…

It just shows how completely subjective it is, and that "technical debt" is becoming an excuse for anything and everything.

I know someone who says all the time that what they want is "The cheapest, fastest (least time to complete), most predictable thing to get something done" and "that if it needs fixing, it can be done when the customer pays for it"

Even green field projects there wind up with significant technical debt in under a year or two.

Re: A Field Study on Technical Debt

#46

Post by ThrustVectoring »

tracker1 wrote: post #42
mikekchar wrote: post #38

Earlier quoted context omitted.

The thing that is very frustrating in the "There was never time to change decisions..." bit is that there often is time. If you are curious about what I mean, I invite you to try a little experiment. For a few weeks (2-4 should be sufficient) tell people, "If you see something wrong with the design, refactor it as soon as you see it. If you need some extra time on your story to compensate for that work, just bring it…

As a developer I've had some very good and very bad experiences... usually centered around two issues.. 1. I am not a morning person and am consistently late, I get work done, but not at 8/9am on the dot. And, 2. because I will take the time to understand what I am working on... this usually results in some refactoring and generally less code in the end. I once saved enough code in size to include lodash, and eventem…

From the outside, it's rather hard to tell the difference between someone getting problems that are "inherently simple" and someone spending time finding simpler solutions to problems.

Re: A Field Study on Technical Debt

#47

Post by PopeOfNope »

mikekchar wrote: post #38
tbrownaw wrote: post #27

Earlier quoted context omitted.

The reason I bring this up is I am surprised that architectural choice is overwhelmingly the top technical debt concern. That doesn't seem right. I would expect it to be poor code due to time constraints. 1. The system grew alongside the devs' understanding of the problem space. There was never time to change decisions that were later found to be not the best (and the older such a decision is, the harder it is to fix…

The thing that is very frustrating in the "There was never time to change decisions..." bit is that there often is time. If you are curious about what I mean, I invite you to try a little experiment. For a few weeks (2-4 should be sufficient) tell people, "If you see something wrong with the design, refactor it as soon as you see it. If you need some extra time on your story to compensate for that work, just bring it…

For the people who don't refactor, the reason they usually give is: "There is no time to refactor".

My #1 reason to avoid refactoring code is because that code has been there, is battle tested and hasn't had a bug filed against it in months. That is not my first instinct, either. There are lots of things I see that I had written months ago that I badly want to rewrite every time I see it. I have to restrain myself because it's not just the time spent refactoring. It's writing tests (if you're into that sort of thing). It's getting QA to hammer on it some more. It's fixing all the little bugs that you thought you had fixed that you re-broke. It's all the little bugs you've never seen before because this is a new design and you're not perfect.

Most of the time, it's not worth the refactor, even if it does slow down adding future features to that particular area. There are, of course, two exceptions: 1) if you're constantly playing bug whack-a-mole on a particular section and 2) if a section of the code you're working on is constantly changing. I grasp every opportunity to hold a meeting, stand on the nearest chair, strike a dramatic pose and shout "We are rewriting the loading system... FROM SCRATCH!" My project manager then tells me to get down and lay off the coffee, but that's ok, I've had my moment.

Re: A Field Study on Technical Debt

#48

Post by makeitsuckless »

tbrownaw wrote: post #27
stevecalifornia wrote: post #3

I have never worked in an environment where new employees didn't show up and declare that the existing infrastructure sucks. Knowing this, I caught myself doing the same thing. Reflecting on it, for me it was a coping mechanism. I was overwhelmed by all the new things and didn't understand why this was setup that way, etc. The reason I bring this up is I am surprised that architectural choice is overwhelmingly the to…

The reason I bring this up is I am surprised that architectural choice is overwhelmingly the top technical debt concern. That doesn't seem right. I would expect it to be poor code due to time constraints. 1. The system grew alongside the devs' understanding of the problem space. There was never time to change decisions that were later found to be not the best (and the older such a decision is, the harder it is to fix…

I have found the #1 source of architecture/reality mismatches over time being that "business" has deliberately kept developers only partially informed on a "need to know" basis.

To be clear, there was nothing malicious about it, it's just that many stakeholders only give their short term needs as input, not the long term strategy that's discussed behind closed doors in the board room. The big problem here is that non-engineers don't get that some strategies don't simply add to the problem space, but fundamentally change it.

"Why the fuck didn't you tell us sooner?" is one of the most common phrases in software development.

Re: A Field Study on Technical Debt

#49

Post by nbicdugfeiljij »

I work in an organisation that has a large technical debt. The organisation manages at least $A60b of member's assets, and is overseen by the Australian Tax Office. It also is very visible politically. These three factors make it extremely conservative in terms of change.

However, change is imposed on it inevitably from the outside, so instead of making large-scale changes to its architecture, it tries to keep up with the market by making thousands of small hacks. The original architecture was not designed to cope with this, so it has become hack upon hack upon hack. I should be employed (and paid above-average) in this jobs for decades to come.

Re: A Field Study on Technical Debt

#50

Post by [deleted] »

nothrabannosir wrote: post #14
pjungwir wrote: post #11

Earlier quoted context omitted.

As a first-year programmer a project manager said to me, "I've never heard a programmer praise another's code. It's always, 'This is crap!'" So I always try to be slow to criticize. There is a lot of crap, but things might not be as simple as you think. I really believe we should take more time to read and understand before we write. Or think about G.K. Chesterton's fence: https://en.wikipedia.org/wiki/Wikipedia:Ches…

> You should resist someone who says, "I don't know why this is here, let's get rid of it!" Only get rid of something if you do know why it's there! I know this is orthogonal, but please try to avoid these situations by commenting code which people might wonder exactly that of, in the future. :(

[deleted]
Post reply on HN