Live data from Hacker News

A Field Study on Technical Debt

blog.sei.cmu.edu

11–20 of 81 posts

Re: A Field Study on Technical Debt

#11

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:Chesterton%27s_fence

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!

Re: A Field Study on Technical Debt

#12
post #8
post #7

Earlier quoted context omitted.

where are you working or interviewing? I think, at least in sfbay, it's safe to assume git. And probably some CI tool. This is true across my personal sample of perhaps 15 companies that I know well enough.

You would be surprised. Even in the Bay Area. The Bay Area is better than most places, but the moment you aren't dealing with a purely software shop, the probability they don't have this stuff goes through the roof. The PCB design tool Altium only has provision for using Subversion (which is fine, thanks), but the number of people who actually USE it is miniscule.

Sorry about the downvote! accidental keypress!

Re: A Field Study on Technical Debt

#13

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.

Re: A Field Study on Technical Debt

#14

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…

> 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. :(

Re: A Field Study on Technical Debt

#16
post #4

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…

[deleted]

Re: A Field Study on Technical Debt

#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's actually not really the code per se, it's the abstractions and how they fit together--very specifically, to what extent the abstractions cohere, to what extent they are coupled, and how narrow are the interfaces. Give me a code base that nails these qualities (narrow interfaces, minimal dependencies) and all else (duplicate code, inelegant code) is in comparison NOTHING to deal with.

So the cost of code is almost entirely related to its _architectural soundness_ (to what degree it's coupled, its interfaces are too wide, etc.)

The biggest and prevelant fallacy of our industry is this notion of technical debt. Because the notion implies that it's somehow necessary. It's not necessary.

The ability to build and evolve architecturally sound code is a function of skillset. If the skillset is there, there is no necessary extra cost. In fact, for people that have this skillset it costs MORE to depart from instincts and couple code, create wide interfaces, etc.

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 know all the objections here (it takes time to understand your use cases, etc.), but the objections nearly always miss the fact that architectural soundness and things like code scope/flexibility are ORTHOGONAL properties. You can have very specific code that does very specific minimal-viable product type things ... but this has nothing to do with whether the code is architectural sound or not.

As long as we continue to think of techincal debt as something that's somehow necessary and something to be negotiated we will always be missing the point. The point is that we need to produce workers with the right skillset. There are so few people that have it--which is entirely a failure in our academies, educators, training systems... To keep talking about technical debt and not about how to acquire the architectural skillset is to keep chasing our tails.

Re: A Field Study on Technical Debt

#18
post #4

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…

Are you a consultant? It would make sense that companies that need to hire a consultant for these types of things are the companies that aren't currently doing them.

Re: A Field Study on Technical Debt

#19

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 regardless, any attempts to address technical debt must necessarily begin with a common understanding of what technical debt actually is.

I've rarely seen teams agree that understanding and I think that contributes to their problems.

Re: A Field Study on Technical Debt

#20

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…

Half of the time, the build system of companies I join is unnecessarily complicated. I often end up simplifying things once I get a handle for how it works, creating nice one command deploys or workflows that don't require chaining multiple things or memorizing a gazillion abstractions. Meanwhile, people often waste lots of times on inefficient build tooling and multiple steps to get to the end goal.

None of the companies I have been at created a good model system (although one came close, the employee responsible left due to the startup acting like a consultancy instead of focusing on a quality product) - this has often bit companies hard as data structures start mutating due to changing API & changing requirements, making certain things such as offline caching more difficult.

Architectural choice tends to roll into poor time constraints since poor time constraints puts even more pressure on the code base when poor architecture is involved.

Post reply on HN