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

61–70 of 81 posts

Re: A Field Study on Technical Debt

#61

Post by davidgerard »

makeitsuckless wrote: post #48
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…

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…

Quite a lot of the Scrum process is the valiant attempt to extract coherent requirements from an end user. You should be so lucky as for them to have a coherent plan at all, let alone a secret one. Insofar as they do have one, in my experience there's always a few bits with magical flying unicorn ponies as a requirement they'll get to in time.

Re: A Field Study on Technical Debt

#62

Post by zo1 »

nbicdugfeiljij wrote: post #49

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 wit…

Don't underestimate the value/reward/fun/etc that you can get from a fresh project. New problems, new development process, the chance to re-iterate past designs and architectures, integration with existing/old/legacy systems, and a host of other things.

That's my bit of advice to you on that, as it reads a bit like you're very comfortable and expecting it to stay that way for "decades to come".

Re: A Field Study on Technical Debt

#63

Post by nbicdugfeiljij »

zo1 wrote: post #62
nbicdugfeiljij wrote: post #49

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 wit…

Don't underestimate the value/reward/fun/etc that you can get from a fresh project. New problems, new development process, the chance to re-iterate past designs and architectures, integration with existing/old/legacy systems, and a host of other things. That's my bit of advice to you on that, as it reads a bit like you're very comfortable and expecting it to stay that way for "decades to come".

I do work on my own projects that are fun and interesting. But nothing beats a regular, permanent high-earning job, no matter how boring it is. I personally know a couple of developers who are stressed financially after working for "fun" companies.

Re: A Field Study on Technical Debt

#64

Post by EliRivers »

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…

It can go too far the other way :)

"What's your revision control?" "Git." fine "And Mercurial." Okay "And SVN. And CVS. Some are hosted locally, some are accounts on Bitbucket and GitHub".

"Build system?" "Cmake. And Scons. Depending on which version of the software you're building. And Make. And some bash scripts."

Re: A Field Study on Technical Debt

#65

Post by PJDK »

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

Even better, write a test with a name that describes its functionality.

Re: A Field Study on Technical Debt

#66

Post by ryandrake »

kabouseng wrote: post #55
ryandrake wrote: post #39

Earlier quoted context omitted.

I took a development job once, where I learned on the first day: 1. No backups. Emergency plan = several older copies of the product's source spread among hard drives of various former employees' systems. 2. No source/revision control. Current version of the product's source code was literally whatever was on the lead developer's hard drive at the moment. 3. No deployment process. When a release had to happen, above…

Definitely not safety critical software passing any level of DO-178 certification...

Nope, thank goodness.

Re: A Field Study on Technical Debt

#67

Post by ryandrake »

keithpeter wrote: post #52
ryandrake wrote: post #39

Earlier quoted context omitted.

I took a development job once, where I learned on the first day: 1. No backups. Emergency plan = several older copies of the product's source spread among hard drives of various former employees' systems. 2. No source/revision control. Current version of the product's source code was literally whatever was on the lead developer's hard drive at the moment. 3. No deployment process. When a release had to happen, above…

Sounds like a small company making a niche product. What were you able to do to improve the situation? Which issue did you tackle first (documentation of processes backwards or source control forwards)?

I'd like to think I left the situation far better than I found it.

Tackled source control and issue tracking first since they were low hanging fruit. Next came basic (manual) backups. My background is not in putting together general office-wide IT solutions, so I did not feel qualified to recommend any specific package. After that, it was on to a sane build and deployment process that involved a dedicated build machine and included QA. After a long time I could start safely making code changes to clean the actual codebase up.

I think you'll see this a lot in manufacturing companies who sell physical hardware. The embedded software is a critical part of the product, yet it's not treated with much more care or seriousness than anything else on the BOM. Night and day difference between working at a company where software _is the product_ vs where software is just one of the many components that goes inside the product.

Re: A Field Study on Technical Debt

#68

Post by dragonwriter »

shoo wrote: post #36
dragonwriter wrote: post #22

Earlier quoted context omitted.

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

> > 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. Agreed, it is not the only example, but perhaps it is a good one, as that is a particularly important form of debt that makes the code harder to safely change. I.e. it is a form of technical debt that makes it more expen…

I think "code without tests" is a fine example of technical debt or legacy code, but using it as the definition of either disregards the importance of everything other than tests that goes into making systems maintainable.

Tests are necessary but not sufficient. (Particularly, tests embody

Re: A Field Study on Technical Debt

#69

Post by wellpast »

dasil003 wrote: post #41
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 f…

This is the fallacy I was referring to--architectural soundness has nothing to do with anticipating change.

The "choice" your engineer faces to shoehorn a feature in [1] versus implement it in a way that optimizes for soundness (decoupled code w/ narrow interfaces) is not a choice if the skill set is there--i.e., if he/she has trained and practiced the right skill set.

[1] (By 'shoehorn' I assume you mean implement it in a way that leaves the code base in an unsound state.)

Re: A Field Study on Technical Debt

#70

Post by dasil003 »

wellpast wrote: post #69
dasil003 wrote: post #41

Earlier quoted context omitted.

> 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 f…

This is the fallacy I was referring to--architectural soundness has nothing to do with anticipating change. The "choice" your engineer faces to shoehorn a feature in [1] versus implement it in a way that optimizes for soundness (decoupled code w/ narrow interfaces) is not a choice if the skill set is there--i.e., if he/she has trained and practiced the right skill set. [1] (By 'shoehorn' I assume you mean implement i…

You can't just reaffirm that without evidence and an argument. It is self-evident to me (and I presume every other software engineer here) that different architectures lend themselves to different types of change. If you want to make that claim than you probably should write a dissertation about it because it's quite a controversial claim. But simply stated as if it were unassailable fact is pushing you right into crackpot territory.
Post reply on HN