Live data from Hacker News

We sound like idiots when we talk about technical debt

cyclic.sh

181–190 of 198 posts

Re: We sound like idiots when we talk about technical debt

#181

Controversial idea: Technical debt is something that 'business users' don't need to or want to care about. If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so. You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot…

Yeah I can see why that is controversial. The assumption seems to be that a single developer has agency and is aware of and solely responsible for everything that's going on in the codebase that they may or may not have written. I've been in a situation where I joined a new company and the code base wasn't looking good but my job as a new hire wasn't to redesigh and rewrite the guts of it. My job was to implement new…

"We build our computer (systems) the way we build our cities: over time, without a plan, on top of ruins." - Ellen Ullman

Re: We sound like idiots when we talk about technical debt

#182

Controversial idea: Technical debt is something that 'business users' don't need to or want to care about. If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so. You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot…

> Technical debt is something that 'business users' don't need to or want to care about. Sometimes it's hard to tell your manager: Yes I know you want to track every single coding task in Jira, and you don't see any immediate value to this one, and I'm not going to dispute that, but I am going to do it and you "don't need to or want to care about it". Sucks not to have that autonomy but it's real. That's when you hav…

That's why you sneak it in piecemeal as you go, and leverage the critical path of urgent things that aren't finished yet to get it done.

Re: We sound like idiots when we talk about technical debt

#183
post #3

Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.

I had a conversation that stuck with me a few years ago at a very large company about making proposals for future projects. I had a habit of making very detailed proposals, doing a great job making projections and being accurate about those projections. A VP of engineering pulled me aside after he saw that one of my proposals wasn’t getting traction and told me “None of the people who are writing alternatives to your…

>“None of the people who are writing alternatives to your proposal are doing the analysis you are, that’s why they look better than yours”

Oh wow. Boy have I been bitten by that before :(

Re: We sound like idiots when we talk about technical debt

#184
post #112

Earlier quoted context omitted.

I am not sure that your metaphors actually work when talking about "Technical Debt" in the IT sense of the word. - If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"... - If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future... - If the lawyer who was origi…

> - If the contractor finds asbestos which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"... Obviously someone* put that there. It didn't just install itself. Regardless of whether the contractor installed it themselves or not, the reality is it's there now and needs to be removed. In other words, the analogy still holds regardless of "oh they put it there" > -…

It was a way to illustrate the metaphor: I am just as "new to the legal system" as I am at asbestos removal or car repairing... but I have enough experience with software development to understand why "tech debt" is a pretty hard concept to sell to business.

In any case my point is not "there is no tech debt if you created it yourself" it is more about "from the point of view of business tech debt is not something they care about: it is sonething they expect to just be sorted out transparently or that should not even happen". After all, Microsoft never bills them for "tech debt", it just ask them to reboot to update their laptops, no?

I am not saying this is fair, or right. I am just trying to explain why mentioning "tech debt" falls on deaf ears.

Re: We sound like idiots when we talk about technical debt

#185
post #149

Earlier quoted context omitted.

"They made the mistake of hiring people that were not capable of surfacing risks." Exactly the problem we always deal with: Business tends to distrust Tech because we always seem unable to stay on top of things we build ourselves

There are two types of tech debt in my experience, things get out of date because they weren't maintained and it's harder to do now years later than absorbing some of that work a little at a time throughout the years. And the other kind is because of poorly written code which is often caused by poor business practices and changing requirements.

I don't now what your experience is regarding sw development (especially corporate): - in my experience technical debt is often due to:

"There is never enough time to do it right, there is always time to do it twice"

Re: We sound like idiots when we talk about technical debt

#186

Earlier quoted context omitted.

Part of the problem is that the job of an accountant, lawyer, electrician (and presumably a mechanic) has that responsibility and duty of care imposed by law. If a client is pushing you to cut corners that are illegal to cut, you point them at the law book and tell them to piss off with their meddling. And because it's illegal, everyone in your jurisdiction will have to do the same thing, thereby assuring that the ou…

Without legally imposed duty of care, the only thing that can be done to draw a line in the sand is to commit (collectively) to maintaining a reasonable level of professional practice. Simply do not entertain probing and meddling. "It's going to take a little longer because the software is complex and it takes some time to untangle it" is all you need to say. Whether you refactor/test/document it in the process of un…

That won't work. As I said, for developers, this is a Prisoner's Dilemma scenario. It simply takes enough defectors to fill jobs at companies that don't care about quality, and you lose any collective power you had as a group.

Re: We sound like idiots when we talk about technical debt

#187

Earlier quoted context omitted.

If dealing with technical debt has a toll on one’s mental health then maybe they should transition to a different profession. Dealing with technical debt is part of your job description. Most people don’t have the luxury of ignoring the hard parts of their job.

It’s not about luxury, it’s about increasing output efficiency through (human) resource management. I asked if there was any available research that measures the effect of tech debt on mental health and therefore output efficiency. TBH, I’m not really sure which part of my original comment you are addressing. Edit: clarification.

I’m addressing the premise of your question. If someone’s mental health is affected by technical, then that role is not well suited for them. No one should have to work a job where their mental health is constantly in jeopardy.

Re: We sound like idiots when we talk about technical debt

#188

Earlier quoted context omitted.

It’s not about luxury, it’s about increasing output efficiency through (human) resource management. I asked if there was any available research that measures the effect of tech debt on mental health and therefore output efficiency. TBH, I’m not really sure which part of my original comment you are addressing. Edit: clarification.

I’m addressing the premise of your question. If someone’s mental health is affected by technical, then that role is not well suited for them. No one should have to work a job where their mental health is constantly in jeopardy.

> No one should have to work a job where their mental health is constantly in jeopardy.

Agreed. But you’re using the term mental health as mutually exclusive to mental unhealth (unhealthiness?). I’m asking what the effect size is (assuming that there is an effect) and whether it can be modeled on a curve.

Edit: (addendum). It should go without saying that many people work in environments that are to some degree unhealthy for them and don’t have the luxury of switching.

Re: We sound like idiots when we talk about technical debt

#189

Earlier quoted context omitted.

In your scenario your manager appears to be your adversary and not your manager. Those comments are what I would expect from a stakeholder, but not a manager. Your manager should provide a unified front to business and senior management. You two should agree on the correct approach. If your manager doesn't believe that your team should build things correctly and minimise technical debt then he's a terrible manager an…

> If your manager doesn't believe that your team should build things correctly and minimise technical debt then he's a terrible manager and you should leave. If you or your manager believe that there is only one "correct" option and that technical debt should always be minimized (vs being balanced against other factors), then odds are you're bother either terrible or very naive. In almost every moderately sized piece…

While true, this doesn't change the premise. Both parties should agree on the "correct" approach in the context of this discussion: minimising technical debt.

Re: We sound like idiots when we talk about technical debt

#190

Earlier quoted context omitted.

In your scenario your manager appears to be your adversary and not your manager. Those comments are what I would expect from a stakeholder, but not a manager. Your manager should provide a unified front to business and senior management. You two should agree on the correct approach. If your manager doesn't believe that your team should build things correctly and minimise technical debt then he's a terrible manager an…

Your manager is always potentially your adversary: after all, they can fire you if they are unhappy with what they are seeing. Not to mention that some managers simply are adversarial, period. When you apply to a company, you can rarely choose your manager, and sometimes cannot work under a different manager without leaving the company entirely.

I've had adversarial managers in the past. Unsurprisingly, the team underperformed and the culture was terrible, so I left. I don't agree that one's manager should be one's adversary. I've worked with many managers who work with me instead of against me. This is a crucial difference.
Post reply on HN