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

51–60 of 81 posts

Re: A Field Study on Technical Debt

#51

Post by logn »

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

This all depends on the nature of the business, the app, codebase, customers, processes of dev/QA/ops, etc. For example, this cavalier attitude might work at a social media startup but not at a bank.

Re: A Field Study on Technical Debt

#52

Post by keithpeter »

ryandrake wrote: post #39
bsder wrote: post #4

Earlier quoted context omitted.

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…

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

Re: A Field Study on Technical Debt

#53

Post by [deleted] »

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…

[deleted]

Re: A Field Study on Technical Debt

#54

Post by SideburnsOfDoom »

ryandrake wrote: post #39
bsder wrote: post #4

Earlier quoted context omitted.

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…

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…

>took a development job once, where I learned on the first day: No backups, No source/revision control, No deployment process, No dependency management, No bug tracker.

And that is why one should always ask about these important things before the first day, i.e. during the interviews, before you decide if you want the job or not. Fortunately I'm in a position that the above would be a near-automatic "no" from me.

edit "Near" automatic as there might be a way out if the company knows that they need to improve drastically and has the will to do it. The other response "what were you able to do to improve the situation?" is key.

Re: A Field Study on Technical Debt

#55

Post by kabouseng »

ryandrake wrote: post #39
bsder wrote: post #4

Earlier quoted context omitted.

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…

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

Re: A Field Study on Technical Debt

#56

Post by tome »

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…

> they do the math in their head (unconsciously) and determine that they will be rewarded more and criticised less if they do feature work without refactoring

Great point. They know they've been told they have time but they don't actually believe they have time.

Re: A Field Study on Technical Debt

#57

Post by collyw »

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…

Sounds like a system I worked on for an investment bank. Sure you will be employed for years fixing hack upon hack, but its not very rewarding work (in the non financial sense).

Re: A Field Study on Technical Debt

#58

Post by hyperman_ »

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…

A few years ago we introduced svn in our company, to replace PVCS. After 4 years, we managed to hunt most of our source code down and get it commited somewhere. Now, we have loads of contractors, some good, some bad, most cheap, and almost nobody longer than a few months. After seeing what insane things some of these guys managed to do in subversion, I simply don't dare introducing git: The history rewriting features like rebase in their hands scare the hell out of me. At least with subversion, i know that what's in there stays in there. git is great if you can trust your people, but svn is a better choice in a large political company that does not care about what happens to its code.

And dont get me started on the abuse of backups or build systems.

Re: A Field Study on Technical Debt

#59

Post by kctess5 »

shoo wrote: post #34
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…

This is very wise. You try to make the best architectural decision that you can at the time, with the knowledge and resources you have available. Time passes and you learn new things -- maybe the problem changes, or your understanding of it improves, or your understanding of alternative implementation strategies improves. For whatever reason, you can now imagine a new architecture that would be superior, if only it w…

Disclaimer I haven't watched the presentation, though I do have first hand experience refactoring large systems that grew slowly over time.

Based off of your edit's description, this technique feels like a patch that inevitably fall apart. It relies on the assumption that your team can correctly identify the centers of uncertainty, and that that uncertainty model will continue to apply. Thinking about such things is an excellent idea, but it is not sufficient - uncertainty is, after all, uncertain.

I think in many cases the more important thing is to create an abstraction that allows you to perfectly represent your existing business logic in the most concise way possible. This should let you cut down on the number of edge cases outside the model, and generally simplify the system. Simplicity in specification is important, because it will allows newcomers to quickly understand the inner workings of your code, quickly correlating business logic with real code - if they can understand it, and can work within it, then they will not be tempted to hack around it (which is the root of code deterioration). I strongly believe that human friendliness and understandability should be key design goals in ANY new system, not an after thought.

So long as no one breaks the abstraction, the 99%, day to day changes should be easy. When you finally do hit a case that requires a significant abstraction change, then your concise code will make it obvious that it's outside of your abstraction model, and can evaluate options at that point.

Re: A Field Study on Technical Debt

#60

Post by davidgerard »

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…

Part of this is the fresh-eyes effect. Just having someone new look at things should result in good stuff happening in the first three months.
Post reply on HN