Live data from Hacker News

We sound like idiots when we talk about technical debt

cyclic.sh

151–160 of 198 posts

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

#151

Earlier quoted context omitted.

Controversial because it's disconnected from reality. You're putting ALL the responsibility on devs as if they are free to present any estimate they like that will then be then accepted without questions or negotation by management. In this fantasy land management is presumably operating in a vacuum with no pressure from customer deadlines, costs, investors, long term product roadmaps etc. I don't know about you but…

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.

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

#152
post #112

If the contractor finds asbestos, he's allowed to quote me more to do the work I hired him for. If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work. When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are rene…

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"

> - If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future...

That is exactly what every car dealership does with their "powertrain" warranties and service packages.

> - If the lawyer who was originally part of the team that helped draft the old law...

AAAAAAAHHHAHAHAHHHAHAAAA New to the legal system?

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

#153

Earlier quoted context omitted.

Controversial because it's disconnected from reality. You're putting ALL the responsibility on devs as if they are free to present any estimate they like that will then be then accepted without questions or negotation by management. In this fantasy land management is presumably operating in a vacuum with no pressure from customer deadlines, costs, investors, long term product roadmaps etc. I don't know about you but…

> Bob says it would take 2 Tell Bob I wish him the best of luck in this endeavor, he's clearly a better programmer than I am.

Bob can remain lucky for longer than you can keep your credibility intact (aka "markets can stay irrational for longer than you can remain solvent"). Ultimately, that stance gambles on Bob's luck running out and his lack of skill being exposed in time for you to profit from it.

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

#154

Earlier quoted context omitted.

Not sure I agree with the theme of this take. Technical debt can be significant and take months to address on a large codebase. This take also places a lot of blame on the devs who have to work on tech debt, where in reality, it's often another dev who wrote the original code(usually several years ago, and no longer at the company). Things are more complicated than "just deal with it and hide it under a rug".

> Technical debt can be significant and take months to address on a large codebase. I think the premise is that if you've got months of technical debt built up, you've already screwed up. If you (and everyone else on your team) refuse to ever take shortcuts, you'll end up debt free. If you're already in a situation where you have mounds of debt, yes, you can't just increase your estimate for current tasks.

"If only everyone" is a version of the Prisoner's Dilemma. I don't think we've got that one figured out yet.

Besides, if your working style overly focuses on proper engineering while other things are on fire, the company could die.

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

#155
Tech debt is a thought terminating cliche. Progress is possible more easily if we talk in a Markov fashion: under present circumstances, to get X, we need to do Y.

The fact that some other Z lead to debt T is pointless CYA discussion. One can reasonably ask if a team is well performing if it frequently finds the need to redesign, but that’s a team ability meta discussion not an execution decision.

Execution is just “we’re here; we want to be there with a hope of being this other place in future; how do we get there”

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

#156

IMO: software engineers have a professional responsibility to mitigate technical debt (among other things). Accountants do not _ask permission_ to reconcile the books with the bank account. Mechanical engineers do not _ask permission_ to replace a part that is in danger of failure + could cause injury. Electricians do not _ask permission_ to use the right size of wire for a circuit. Software engineers should not _ask…

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 outcome of this particular Prisoner's Dilemma is rigged in advance except for the most foolish/risk tolerant who are willing to break the law.

The software profession has no such thing, for the most part. So clients will keep probing and meddling, just like toddlers who want to know how much they can get away with before their parents punish the misbehaviour. And if some people die, or suffer from algorithms gone wrong, or are just generally pissed off left and right because of bad software - who cares. Profits are king, right?

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

#157
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 get that a lot of people in IT are very facts-focused, but if you want to actually convince people that they need to act in some fashion, you need to add some emotional weight to your arguments (pulling numbers out of your ass is one way of doing that). Admit it or not, the reason you want the technical debt addressed is primarily emotional. You are frustrated with how difficult it is to work, you fear for the futu…

Fear of project failure is the signal that the company (= your employment prospects) will be damaged. Frustration with how difficult the work is, is a signal that the current path is unsustainable, and that burnout will set in, thereby damaging your ability to work (= your employment prospects).

It's perfectly rational to be concerned about these things. We are not machines - or rather, we are machines that have mental/psychological/monetary needs that have to be met in the course of our daily employment.

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

#158

Earlier quoted context omitted.

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…

That's when you suggest that the historical accuracy of the proposals should be weighed to determine the degree of certainty in future proposals from various sources, right? Let's say person A gives longer estimates but is accurate within 10% more than 95% of the time. Let's say person B gives estimates half as long, but the team runs over by 75% a quarter of the time and by 150% about half the time. Whose proposals…

You'd need to be very strategic in how you point that stuff out. Because straight up saying that numbers from those people have been consistently wrong throws the people bringing them forth under the bus and it will make the people who you're giving the proposals to feel like you're telling them that they are doing a bad job at evaluating proposals given that they did give the final approval on all of them.

You're probably better off just playing the game and making up good sounding numbers. You're less likely to have half the company resenting you and making your life difficult.

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

#159

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…

Controversial because it's disconnected from reality. You're putting ALL the responsibility on devs as if they are free to present any estimate they like that will then be then accepted without questions or negotation by management. In this fantasy land management is presumably operating in a vacuum with no pressure from customer deadlines, costs, investors, long term product roadmaps etc. I don't know about you but…

The real issue in a situation like this is the use of the Agile Story point BS to create competition between developers in order to have leverage exactly this to push back against the Engineering team with. You need to have a Dev-only meeting so Bob doesn't feel specifically called out and talk about how you all want to negotiate the interests of Product/Business with the dwindling engineering situation, i.e. Tech Debt.

Bob, and others like Bob who live to impress management with their personal 'agility', will implicitly feel more pressure to not go against the whole engineering team if you're able to reach even near-unanimity about what that strategy will look like, in this case, perhaps coming to agreement about how certain tasks will be pointed univocally, amongst other possible strategies. Your only obstacle at this point is a head of Engineering whose interested in their own career over and above his team.

Agile SCRUM exists, largely and for the most part in my experience, as an abuse to prevent this kind of 'collective bartering' on the part of Engineering.

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

#160
post #30

People saying "its on you" and "has your boss ever reviewed the code?" have not had varied enough experiences. Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you're fired? I have in fact had my commits gleaned by my boss, told me "no, we're not shipping these 10 lines of code because that goes too far and not what I asked" and then refused to accept the pull requ…

Exactly. Consistently refusing to take on technical debt may work if you are drowning in demand for your skills and can easily switch. I don't think that's the case in most places outside the Silicon Valley.
Post reply on HN