Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We sound like idiots when we talk about technical debt

cyclic.sh

Post reply on HN
Print view View original

131–140 of 198 posts

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

#131

Post by Pamar »

xionon wrote: post #122
Pamar wrote: 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…

I don't understand your point here. In literally all these scenarios, you would still be billed, and it would be appropriate.

My point is: technical debt from the point of view of Business is something that the developers themselves introduced or did not manage properly, so trying to make it look like something beyond their control ("we just found out that in the 70s someone put asbestos under the roof") will sound a bit unconvincing.

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

#132

Post by RHSeeger »

drewcoo wrote: post #126
RHSeeger wrote: post #106

Earlier quoted context omitted.

I disagree pretty strongly with what you've said here. Specifically, part of my job is to make sure my customer is aware of the options and the costs of each of those options. Doing things the faster/less robust way now will have a cost later (re-implementation of some part, etc). And then I do my best to convince them of the approach that I think is best. But only telling them about the option I think is best and _n…

When you get a new heating system are any of the options "fake it til you make it?" Would you pay for any of the options known to be unstable and will have to be replaced in a year? What about the options that require HVAC staff to carry 24 hour pagers? When's the last time you got a whoopsie email from that manufacturer because of an outage?

I've had to choose between

- Installing a 3 port hot water line that has an extra, unused port for later (when we furnish the basement) and a cheaper, 2 port line. If we chose the 2 port line, it would have cost less now, but incurred additional cost (replacing it) when we furnished the basement.

- Using the old hot air lines (much lower cost, but less efficient), rewrapping the part of the current hot air lines that can be reached (middle cost, middle efficiency), and replacing the lines completely (higher cost, higher efficiency)

- Installing a reserve hot water tank (more expensive, but better able to handle load) or not (less cost, but could result in not enough hot water under load). If we went without the reserve tank and it turned out we were short on hot water on a regular basis, it would cost to add one in (overall, more than just including it at first).

None of those things are choosing between "doing a bad job" and "doing a good job". They are all a choice of how much we want to pay now vs debt we may/will need to pay off later. Ie, a parallel to technical debt. Technical debt doesn't always mean you did a shitty job, it could mean you took certain shortcuts because they accomplished what was needed _today_, but will incur additional cost _tomorrow_.

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

#133

Post by foobiekr »

hermannj314 wrote: post #104

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…

It’s worth recalling the recent hacker news discussion about engineers pulling and shipping unvetted code without any sense of responsibility at all.

Modern SW practices don’t accidentally end up with technical debt, they’ve gotten to the point where they don’t even give limiting it a thought and will happily pull in mountains of other cider’s technical debt on top of their own.

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

#134

Post by Pamar »

alanwreath wrote: post #119
Pamar wrote: 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…

I must not understand technical debt...all of the scenarios you're mentioning seem like they could easily map to a technical debt scenario - a developer takes a certain strategy that is no longer valid (even technical debt that isn't recognized early on as being something that will have to be changed more than likely soon, is still technical debt in my mind -- your ability to recognize technical debt early on just me…

See my other answer below: trying to convince the payers that there are extra costs due to "technical debt" accumulated somehow during the lifetime of a sw project would sound "unconvincing" because from the point of view of the business that would be part of the job of the same people that are now asking more money/time/resources to fix it.

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

#135

Post by RHSeeger »

Gareth321 wrote: post #123
zaptheimpaler wrote: post #84

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…

> 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 of work, there are multiple options and there's a choice of which one to take based on various priorities (ie, the best option varies depending on multiple factors).

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

#136

Post by [deleted] »

Pamar wrote: post #131
xionon wrote: post #122

Earlier quoted context omitted.

I don't understand your point here. In literally all these scenarios, you would still be billed, and it would be appropriate.

My point is: technical debt from the point of view of Business is something that the developers themselves introduced or did not manage properly, so trying to make it look like something beyond their control ("we just found out that in the 70s someone put asbestos under the roof") will sound a bit unconvincing.

[deleted]

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

#137

Post by dasil003 »

Although this article points out a lot of mistakes that can be made when talking about technical debt, it kind of throws the baby out with the bathwater.

The truth is technical debt is a metaphor specifically designed to be understood by non-technical business people. Technical debt has gained traction as a concept because it does actually give a reasonable indication of the cost tradeoffs of short-term vs long-term implementation decisions that was formerly very difficult to explain.

Of course, all analogies are flawed, and the devil is always in the details. Over time "technical debt" has been used to describe all manner of problems which don't really fit the rubric as interpreted by a business person, for instance: changing requirements, UX debt, bitrot, junior coders, bad guesses about the future, etc.

What it boils down to is effective communication: the mental model of your audience, and your reputation. If you are in an org where there is no understanding of technical quality and no trust in engineering, then the assumption will always be that you're sandbagging, and frankly this is no place for an honest hard-working engineer to be. On the other hand, even if there is a strong engineering culture with a CTO who understands the details and has an equal voice at the table, you can't just cry "technical debt" at every turn because engineering is more complicated than that. There are usually paths to deliver value while improving quality over time, but sometimes it requires different kinds of pushback. Reframing the problem with alternate sequencing or 80/20 proposals to product or business stakeholders is often more fruitful than endless negotiations centered around resource numbers. However it all stems from trust. If you as an engineer or engineering manager can demonstrate you understand the needs of the business and can more efficiently transform engineer hours into business results, over time that gives you the reputation to be heard when it comes to long-term tradeoffs.

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

#138

Post by nickysielicki »

jimbokun wrote: post #125

> The difference between a user story taking a day or 3 days is negligible compared to its business value. Companies and their leaders care about revenue and costs. They care about customers and growth. They care about time to market. Um, taking a day vs 3 days is huge. Because the cost of each task is now 300% of what it should be. Time to market is also absolutely impacted by technical debt, for the same reasons. D…

> Describing this to company leaders in ways they understand is pretty straight forward. "If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward."

I’d argue that technical debt that can be resolved in a week is not real technical debt.

And when you’re dealing with “real” technical debt, it’s hard to substitute numbers into that sentence without lying through your teeth. “It will probably take us a month to two months to fix this problem and in terms of product launches it’s completely ambiguous how much faster we’re going to be.” isn't nearly as easy of a sale.

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

#139

Post by cweagans »

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 permission_ to do the right thing. Some component of your software is fragile? Write tests for it. Difficult to add one more thing to that already tangled mess of spaghetti code? Untangle it. No idea how some part of the system works and there's no documentation? Figure it out and then _write documentation_. Security patches need to be applied? Apply them.

There is a balance to strike here of course: you still have to deliver things. Do refactors in small-ish increments if possible (don't just rewrite the entire system). Write a couple tests every time you change something. Whenever you have to ask a question about something, write down the answer. A product owner may not understand the importance of doing these things, but that is not something they need to give their input on. Code organization, testability, etc are not product features. They are engineering details - details which engineers are obligated to pay attention to.

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

#140

Post by CyberRabbi »

Great post. One of the major problems is that software engineering is saturated with green devs who recently transitioned from hobbyist coding and don’t fully understand the responsibilities of being a professional. Hobbyist projects are rarely held to external constraints. Usually when the hobbyist dislikes the code he has thus far written, he will rewrite it instead of iterating on it because he has that luxury since nothing depends on his project. Unfortunately in the real world, we have to consider other factors aside from what the author prefers to work on.

This hobbyist mindset is damaging to the software engineering profession in a myriad of other ways.

Post reply on HN