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

21–30 of 81 posts

Re: A Field Study on Technical Debt

#21

Post by kyllo »

bsder wrote: post #4
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…

In most places I have been, the infrastructure DOES suck. First question: "Backups?" followed by "When was the last time you did a restore?" Second question: "What's your revision control?" For all of my slagging on git and the people who use it, I am thrilled if I hear "CVS" or "Subversion" because it means they're using version control . "git" or "mercurial" tells me I have an team that has some level of clue. Thir…

My favorite right now is pom.xml files declaring dependencies that don't exist in the corporate Maven repository, nor in any public one. Kinda defeats the whole purpose of using Maven if I have to go download jars manually.

Re: A Field Study on Technical Debt

#22

Post by dragonwriter »

philbo wrote: post #19
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…

> I don't classify these as technical debt because Apologies if this is too meta, but that is the most interesting part of your comment for me. It conceals a massive assumption which all devs make, resulting in very different conclusions. What IS technical debt? My own preference for the answer is Uncle Bob's description, which is this: technical debt is any production code that does not have (good) tests. But regard…

> What IS technical debt?

Any feature of the code or tech stack that increases maintenance/operations cost compared to alternatives.

> My own preference for the answer is Uncle Bob's description, which is this: technical debt is any production code that does not have (good) tests.

That's certainly an example of technical debt.

Re: A Field Study on Technical Debt

#23

Post by brudgers »

There were 39 separate business units represented among the three companies

The context in which this study was done is quite different from an early stage startup. This is not surprising since the SEI tends to focus on big engineering solutions to big problems [which is not to say that its insights and guidance aren't applicable]. But it is important to realize that they focus on engineering in situations that are relatively stable over the long term (29% of systems studied over 10 years old), and almost 1/3 of the systems studied were embedded where changing the software is particularly difficult and throwing more hardware at a problem is not cost effective.

Re: A Field Study on Technical Debt

#24

Post by jschwartzi »

InclinedPlane wrote: post #13
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 does suck. Most code sucks. We just get used to it. Doesn't mean it doesn't work, doesn't mean it's not valuable. But it still sucks. As for architecture being the biggest technical debt problem that should be obvious. Architecture is often the most difficult thing to change after the fact.

"Good code" is often a euphemism for understandable code.

Re: A Field Study on Technical Debt

#25

Post by PopeOfNope »

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…

Notice that nowhere in the article is there any mention of what a good architectural choice is, nor any mention of the perception of debt in relation to the size of the system[0]. My personal experience with architectural choices is that all of them are great early on when the code base is small. As that code base grows, they all suffer under the weight.

[0]: 100k-1M is a very large range. Kudos to them for filtering out small code bases, but a graph of these perceptions measured against code size would have been helpful.

Re: A Field Study on Technical Debt

#26

Post by Joky »

pjungwir wrote: post #11
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…

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 :)

Re: A Field Study on Technical Debt

#27

Post by tbrownaw »

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).

2. The problem space changes over time. Either because the outside world changes, or because of scope or scale increases. This means that even good architectural decisions can become bad over time.

Isolated pieces of bad code can be fixes when/if they need to be touched for some other reason. Fixing currently-inappropriate architecture takes a bit more effort.

Re: A Field Study on Technical Debt

#28

Post by eitally »

bsder wrote: post #6
stephentmcm wrote: post #5

Earlier quoted context omitted.

You need to look harder then, we tick all three and even use Gitflow. With back ups used all the time for testing live state locally and a CI 1-click (well 5 or 6 actually...) deploy to Test/Stage/Prod.

Congratulations. You're the 1%, you don't need my services. :)

I came from an awful IT environment and even my team met your criteria. I think you might be primarily exposed, due to the nature of your work, to the worst of the worst. We had/have a lot of technical debt, but the architectural ones are the hardest to fix (because they cost real capital). You wouldn't believe how hard it is to get sign off on new servers (at some companies). My team nearly made an executive decision to switch to GCP or AWS just to escape our own internal infrastructure group.

Re: A Field Study on Technical Debt

#29

Post by Ologn »

bsder wrote: post #4
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…

In most places I have been, the infrastructure DOES suck. First question: "Backups?" followed by "When was the last time you did a restore?" Second question: "What's your revision control?" For all of my slagging on git and the people who use it, I am thrilled if I hear "CVS" or "Subversion" because it means they're using version control . "git" or "mercurial" tells me I have an team that has some level of clue. Thir…

> First question: "Backups?" followed by "When was the last time you did a restore?"

KDE almost lost hundreds of their git repositories in 2013 because they were not doing backups ( https://news.ycombinator.com/item?id=5432760 ).

Re: A Field Study on Technical Debt

#30

Post by stephentmcm »

bsder wrote: post #6
stephentmcm wrote: post #5

Earlier quoted context omitted.

You need to look harder then, we tick all three and even use Gitflow. With back ups used all the time for testing live state locally and a CI 1-click (well 5 or 6 actually...) deploy to Test/Stage/Prod.

Congratulations. You're the 1%, you don't need my services. :)

I'm very glad I don't and all power to you spreading the good word :)
Post reply on HN