On Technical Debt, a conversation with an old engineer
Posted by Humdaak_9000@reddit | ExperiencedDevs | View on Reddit | 104 comments
I was explaining the concept of "technical debt" to my dad, a PhD chemical engineer with about 40 years of experience.
Apparently in Real Engineering, they didn't need a special term for this bullshit, because timelines are saner.
Bet more than one set of eyeballs saw the thing before it went out the door, too.
WesolyKubeczek@reddit
Sounds like someone who never had a house renovated
lupercalpainting@reddit
Brother what are you talking about? Every car manufacturer has to continue supporting legacy models for decades. Also patching? Yeah in auto that’s a recall.
theDarkAngle@reddit
Recalls are pretty expensive for the manufacturer and they try to avoid it. If it were like modern software they would ship the cars knowing they'd have to issue recalls for half of the components.
Really it's apples to oranges in a lot of ways though. Software is not really like a car, at least web software. It's more akin to a business or a government office or something. It's an ongoing thing that can respond to changing needs in the market.
Aware_Magazine_2042@reddit
Well. That’s simply not true. They just call tech debt something else: trade offs and limitations.
I spent a lot of time working on cars, planes, and boats. I’ve worked on many different iterations of the same family of engines before I became an engineer and they deal with the same bullshit we do, their iteration cycles are just much longer than ours. They’ll produce 100,000 of one iteration of an engine before they update it, but when they do, they always change a lot on the engine but not enough to warrant a whole new name.
Sometimes these changes are caused by the bean counters saying something needs to be built cheaper, sometimes its because they try something new and it doesn’t work out and they revert it.
The difference is that software engineering is engineering, maintainence and assembly all in one, so of course we see the shit sooner.
HowTheStoryEnds@reddit
The big difference: it's explicitly documented and generally understood.
theDarkAngle@reddit
Well also software is unique in terms of how easily you can change it even after shipping.
UntestedMethod@reddit
Or in pharmaceuticals, they call it side effects
SoylentRox@reddit
No no no. This is NOT technical debt. Technical debt is when engineers build something one way, and later learn a better way to do it, but are UNABLE to fix the problem fully because of limitations from the previous solution.
Example: in real world engines, even when engineers learn better ways to build them, they can't change things like the bolt hole locations or size or layout of the output shaft.
This is because there are now vehicles built around the previous engine, and it's very expensive to redesign.
Strong example : jet fighters. Deep pocketed militaries are willing to pay for substantial ongoing upgrades, but each upgrade has to be compatible with the existing airframes. This is ultimately the reason why redesigns are needed and the Navy doesn't just run F-4 phantoms upgraded until they perform like F-35s. They can't.
ings0c@reddit
That’s not the definition I, or anyone I’ve ever worked with uses.
Technical debt is choosing the short term over the long term, for whatever reason. That might be to meet a deadline; it might be because Bob is on holiday and you can’t figure out wtf his new library is doing so you just put a dirty hack in until he’s back; it might be putting this new code in one repository when the best place for it is another so that you don’t have to change the CI/CD pipeline (lol semicolons)
It’s the stuff that you know isn’t right and will eventually come to bite you, but you say not today.
If you don’t know how to do it any better, that’s just your best effort at the time. We all learn as we go and no one can expect you to do better than you know how.
SoylentRox@reddit
It's often decisions that were right for the time but turn out to be wrong later at scale you can't undo without cost that your management isn't willing to pay. That's what I am saying.
I work on a project mired in technical debt and am fairly well aware of HOW we got here. There were some mediocre developer contributions, some contributions made by people just trying to finish a ticket, and some well meaning but ultimately terrible decisions.
Ultimately the issue is that there's hundreds of thousands of lines where we need to somehow extract WHAT the code has to do, from reading all of it (a lot of the details and features it has aren't needed), then re-implement it all in a more scalable and debuggable architecture and language.
Without AI tools and some other infrastructure this is infeasible.
Aware_Magazine_2042@reddit
Huh? It seems like you’re agreeing with me? This is what I said.
It’s also what I mean by iteration. I’m not talking about going from an f-4 to an f-35. I’m talking about going from f-4a to f-4b. These iterations are limited because of a design choice made due to some trade off the engineers made. That trade off could be manufacturing constraints, cost constraints, technological constraints, and yes, time constraints.
rorychatt@reddit
.... no. That isn't what that means.
Tech debt isn't a term for retrospectively tagging something as an incorrect idea.
Tech debt is a deliberate decision to go into 'debt' (run costs, people costs, architectural trade offs, etc) to achieve another outcome quicker (getting to market, resolving vulnerabilities, cost avoidance, etc).
The key is that tech debt is a decision that is made to trade one for another.
What you are describing are constraints.
jethrogillgren7@reddit
I've never come across that definition before.
Internet definitions match what I'd expect:
Specifically it's the shortcuts taken to save time that then have future impacts. You're often not "unable" to fix these problems, you just need to put more effort in and you'll be in a worse position until you do so. I think I'd also not call it technical debt if someone in my team finds a "better way to do it" - that's just adopting new tools/processes/ideas. Better ways are always evolving, solid software that was built without corner-cutting doesn't suddenly have "technical debt" because new stuff comes out. It just slowly becomes obsolete.
SoylentRox@reddit
Yes garners definition is correct and consistent with my definition. And yes technical debt happens because you are unable to fix the problems for the reason that they are too expensive to fix.
It is not that it can't be done, it won't be done however.
muffl3d@reddit
Yeah fully agree! In fact in other engineering, technical debt is a given because you can't rework your initial design as easily once you've built something. In software, you spend time to rearchitect things but otherwise there's no cost. Yeah I know engineers cost a lot but it's different when you have a whole manufacturing plant built and can't rework it.
There's almost no way you can redesign things to recover tech debt because that'll be high capital costs, downtime etc.
SoylentRox@reddit
In software massive amounts of code and APIs you offered to end users can make it in practice infeasible to rework. Though AI tools that let you "vibe refactor" hundreds of thousands of lines may temporarily relax that limitation.
I say temporarily because like other engineering fields, tools can make it easier to redesign past things, but the state of the art is still hard.
muffl3d@reddit
It depends on the type of engineering I guess. My previous background was in chemical engineering so I can only speak on that front. In chemical engineering, there's almost absolutely no way you can remove tech debt in the way you can for software.
If you built a reactor that can only withstand 500 degrees C but now have a new product that's 600 degrees C? Sorry you're out of luck. Unless you get millions of dollars to build a new reactor, test it, commission it etc. And on top of that, while you're doing that, you need to decommission your old reactor so you can install the new one, which means lost revenue.
On the other hand in software, we've heard of famous stories like how twitter redesigned their whole backend and data storage. Same thing with Netflix and their API. That's possible because in the extreme example you can build something without touching the existing system and supersede it. And you can also revamp parts of it, assuming the system was well designed to handle that in the first place.
SoylentRox@reddit
What you need to understand is just because it's text on a screen doesn't mean these revamps were cheap. Netflix pays it's devs a lot, 500k+ cost per dev per year. (All their compensation bonuses benefits office space laptops and managers).
If it took 20 devs a year to rewrite the API - or more realistically 5-10 core people doing it and 80 or so people spent a few weeks on their parts - that's 10 million.
In addition the change had a nonzero risk of an extended service outage of Netflix itself - part of the reason they pay so much - from mistakes or it let hackers in etc. See how Sony had to shut down their entire online service for months.
In a financial sense even a 1/200 chance of a 1 billion loss is 5 million more.
It's entirely possible for the cost to pay technicians to rip out that 500C reactor, cutting pipes as they go, and swap in a higher temp rated one, welding in a mess of plumbing that changes around the flow (and introduces hidden faults that will later cause a fire in 5 years) to be cheaper than software.
What allows software to be so expensive is highly profitable businesses from it. Your real world business has to pay for feedstock and has competition so your profit margins are limited in a way Microsoft isn't.
muffl3d@reddit
Yes I know major re-architect is costly in terms of dev time and salary. And I agree with you, often it's too costly to address tech debt.
But chemical engineering is just a different whole ball game. I'm talking about pharmaceutical plants and oil refineries. Building such a plant takes years while you can't do anything on it. Real estate costs money too. Cutting out a reactor in a plant is equivalent to switching out a db maybe. But an entire redesign like how twitter/Netflix did? That's almost building a whole plant. And at that point, it's not a redesign anymore.
And that's what I mean by living with the design choices and tech debt in other engineering fields. Often you just live with your choice because there's too much time and effort to make a change. And you wait until your equipment runs till the end of its life cycle. That happens in software too but you can chip away at bits and pieces of it more often in software. A lot of decisions are more reversal.
Changing out a db? Oh just do a db migration. There's time needed to redesign but so does changing the type of reactor in a plant. And that's often more!
muffl3d@reddit
Yeah it's just called trade offs. I was a chemical engineer before being software eng and I was working in a pharmaceutical plant and there were plenty of tradeoffs made in the process design throughout the way.
For example I was once working on designing the cleaning process cycle of a machine and there was a part of the machine that was hard to clean because of a lack of nozzles in a particular location. The elegant way was to modify the machine to add more nozzles and have it cleaned as part of the automated cycle. However that means long downtime and huge investment costs. Instead, the decision was made to dismantle that part of the machine and clean it manually.
That's just like our tech debt. Oh this part of the software is poorly designed and can lead to issues in edge cases? Let's not invest effort in redesigning because it takes too long, let's write an ops tool and have the person on call fix it every time it happens instead.
Engineering is all the same man. About tradeoffs and how to maximize the output of your efforts/resources. The sooner we accept that no one cares about elegant code but focus on output the better. If there's a huge pain point, it's our job to highlight what's the benefit to remove that pain point.
Cinderhazed15@reddit
If you read ‘The Phoenix Project’ by Gene Kim, they talk about how not everything needs to be a technical solution - they talk about how some manual processes are in place to cover security/compliance requirements that don’t require a hyper-focus on the software side… particularly when you are in transition.
MrJohz@reddit
To add to the whole "engineering is all the same" thing, one of my favourite blog series is the Crossover Project, where a guy interviews a bunch of "real" engineers who went into software development and gets their perspective on whether software development is the same thing as other engineering disciplines.
Read all three parts (they're not so long), but I think the most interesting one is the last one, where it talks about what we can learn from other engineering disciplines, but also what they can learn from us.
muffl3d@reddit
Oh that's quite an interesting read! As one of the "crossovers", my vote is a yes too. I'd say writing code itself isn't software engineering. Someone writing an app, or even a full stack website without deep consideration into the architecture, how well it scales and how resilient it is, isn't engineering. It's equivalent to doing a DIY project.
Maybe it's due to my chem eng background - to me real engineering, both software and trad, is trying to design systems/processes/machines that gives whatever desired output in an efficient, reliable way.
I must say it's a lot more structured in traditional engineering because it's a lot more established and there are well known formulas, if not heuristics, to follow when designing something. In software, sometimes there's multiple answers to the same problem. I do see some convergence in software though, especially in system architecture. Design patterns are analogous to heuristics in traditional engineering. So maybe we'll get there some day when design patterns are considered a rule of thumb!
MrJohz@reddit
Yeah, that's my feeling as well. Not all software development is engineering (just like how not all welding metal together is mechanical engineering), but software engineering is a real and important discipline.
futuresman179@reddit
Interested - what differences do you notice in being a software engineer vs chemical engineer? Was one more chill than the other? Is being a chemical engineer in the same ways as being a software engineer?
muffl3d@reddit
I wouldn't say it's more chill or not, it's just different. As a chemical engineer, you work on more mundane/repetitive stuff. There's a lot less design and it's a lot more about optimization.
You would typically own a part of the manufacturing process and find ways to optimize it to increase throughput or reduce cost. Every now and then there (think once a year) might be a new product introduction but your job as an engineer is not to invent the process but modify your system to suit the process.
The bulk of the time would be spent on troubleshooting issues that come up instead. And there's plenty, because of said technical debt or equipment deterioration or sometimes human errors.
I don't think I need to say much about software since this is a software sub but let me know if you want to know more about either!
unflores@reddit
Limitations is certainly an interesting concept. An engineer might say, "this bridge is good up till x tons." For a dev, business comes back next week and needs that doubled. 😂 It's fine, it's part of the field but metaphors only take you so far.
Mundane-Mechanic-547@reddit
Also when we deploy to prod it breaks everything immediately. Like I did yesterday! Woops.
Ragnarork@reddit
This topic brings to mind a great piece of writing from Hillel Wayne, called The Crossover project, that looks at """Real Engineering""" compared to software engineering. I really encourage people to read it: https://www.hillelwayne.com/tags/crossover-project/
Spoiler: Arguments comparing software to "real engineering" have rarely involved people that have done both and the answers and comparisons are interesting.
magefister@reddit
Bruz I know plumbers that will do a non compliant job because they didn’t want to tell the builder they couldn’t do their job properly so they just hacked it in
ahrzal@reddit
Eh, technical debt still exists in real engineering vague handwave towards the local military base
Coneyy@reddit
Yeah, It's just called a limitation. We do the same thing on software anyway, like if we ship an old version it has a limitation in it that the new version might not have.
But because we regularly iterate on the same living, growing codebase, it's helpful to just have another slightly different word for tradeoff/limitations
sobrietyincorporated@reddit
It's an industry specific term. Not a catchall
hatchetation@reddit
I'm not sure there's any definition of technical debt which a majority of people would agree on.
It's a vague metaphor that gestures wildly to accruing liabilities but doesn't say much more.
sobrietyincorporated@reddit
Any ticket that is deemed non-essential product wise but an improvement developer side that keeps getting put off.
hatchetation@reddit
Like setting up better editor defaults? Why the focus on the developer experience instead of the end-user?
... like I said, it's fiendishly difficult to define.
sobrietyincorporated@reddit
If it offers value to the client it will get prioritized. If it's only to improve development or clean up the code to make it easier to maintain, that will get thrown in tech debt.
Like, say you want to update the code base to a new framework but that offers no value to the client, that will get thrown into debt because they won't prioritize it.
wheretogo_whattodo@reddit
I am a chemical engineer and it is 100% false that there is no technical debt in industry.
Humdaak_9000@reddit (OP)
I've had this conversation about plant startups with my dad, too. 16 hours a day for two weeks is bad, but plant startups don't run continuously.
The culture of permanent crunch time blew his mind.
wheretogo_whattodo@reddit
I think you’re taking the anecdotal evidence of a single person and applying it too broadly.
I mean, there are organizations where part of their college recruiting process is keeping you up all night then interviewing you in the morning simply to see how you deal with sleep deprivation. No crunch? Ok.
FuglySlut@reddit
Half the devs think something is tech debt because it's not written the way they would have done it.
AfterForevr@reddit
Oh my goodness I’ve been feeling this more than usual lately. A vocal member of the team has really been on a bender for some time now ranting regularly about how confusing everything is or how much harder it’ll be to onboard new developers (which we do maybe once a year at best rn) than if we were to just write things better
Apologies ahead of time for the incoming rant but gosh it’s had me stressed out more than usual thinking about what they will touch (and possibly break or a bit selfishly on my part I just don’t look forward to them deleting my existing context/ knowledge of the existing code without a good optimization-driven reason beyond just having written it better lol) next or bracing myself to hear their next complaint and trying to not react in a non constructive way. Maybe I should be challenging them more on it and pushing back if I disagree or redirecting their energy but truthfully I just find it exhausting and do not enjoy lately lol
Of the refactors we’ve allowed them to do… one completely broke a business critical system that had to be immediately reverted and caused a multi day outage of one of our services to clean up the aftermath until we finally gave up and purged all the caches.
Another has just as many lines of code (by itself not a great metric I’ll admit) and uses similar functions, similar patterns, but they moved a couple functions into another helper file and split up the business logic away from the technical implementation which is “cleaner code” and makes it look slightly more organized but the several days they spent rewriting it hardly feels worth it. Not to mention that now anyone who ever worked on the old version and were familiar with it have now lost any familiarity with it other than a conceptual understanding of the spirit of how its intended to work but will have to re read all of the code the next time we assign them to touch it. It doesn’t perform any faster, didn’t solve any bugs, just code is reorganized into different structure and has more test cases. Which added even more to the feeling of them thinking it’s just bad design or poorly written or tech debt just because they would have done it differently, rather than any objective improvement
*sigh.
Big-Lab-4630@reddit
You forgot to the ad hominem attack of anything they don't like as being an "anti-pattern".
Managers simply don't understand that argument.
ShoePillow@reddit
Good point, fugly slut.
I tend to do this too, so have learned to keep my mouth shut after seeing how some colleagues struggled with my improved version of the code.
NiteShdw@reddit
A bridge is designed, built, and finished.
Software is never finished. That's where the problems are.
flowering_sun_star@reddit
That isn't really true - a bridge will have a designed lifespan, ongoing maintenance and inspection cycles, fixes, upgrades, and maybe lifespan extensions.
NiteShdw@reddit
But no additional features like software
DamePants@reddit
Bridges can have technical debt. If it wasn’t build wide enough for future traffic meaning it either needed to be expanded or another ridge made close to it. Compare Sydney Harbour Bridge in Australia to bridges built after it.
This is similar scaling problem in software, we might have started with ten thousand users but now we have a billion. We aren’t allowed to rebuild because that’s too expensive and we can’t fit another bridge over that crossing. Instead need to find a way to make more lanes on our bridge without stopping traffic.
Chem Eng and Comp Sci, worked it both industries. I will agree when lives are at stake there typically isn’t technical debt with ethical companies.
NiteShdw@reddit
I don't think your comparison is applicable. A bridge is finished. They don't get improved. They get replaced, rarely before they are 50 years old.
What software is done and then doesn't see a single change for 50 years? It's not the same thing. You can't do agile iterative bridge construction over those 50 years.
DamePants@reddit
To be fair the timescale is different for the two, which is missing from the analogy, likely other things. I currently work on a 25 year old code base and there are large sections that are untouched and there is no desire to change them. I’ve worked on some fairly ancient code bases as far as software goes.
_hephaestus@reddit
I take some issue with the characterization of timelines as “saner”. Sometimes sure, sales teams get rowdy and overpromise, but also a huge part of the value of this industry is quick timelines and the ability to go to market quick and fix later. Sometimes people go too far to accelerate but if a startup tried adopting chemical engineering timelines, someone would beat them to market and the business would fail. On top of what others are saying about the failure modes being less bad, success is less tied to engineering brilliance.
BanaTibor@reddit
It was described many times that software engineering is quite different from physical engineering. While in other professions you engineer a solution through iteration you end up with a "blueprint" for the actual product and a manufacturing process. Then you can work on making it mass producible. In physical engineering building is expensive compared to design. In software engineering building is cheap compared to design. So in SWE we usually work on the end product, and when it is done, mass production is trivial. So in SWE the end product can collect faulty stuff during development which are never truly addressed and end up in the end product, these are called technical debt. It is like you would never fix errors in the later iterations of a product during development phase in physical engineering.
CNDW@reddit
Technical debt is something that exists everywhere. It's more prevalent in software because software is constantly changing. In more traditional engineering, designs are hard fought and either meet physical limitations or are not mutable in any substantial way. Software engineering doesn't suffer the same limitations and often deal with tech debt as a function of the software changing so frequently.
I don't think deadlines have anything to do with it, most technical debt comes from changing requirements making old designs cumbersome.
tcpukl@reddit
So how else do they explain construction projects always being delayed? Especially when it's being paid for by the public.
circularDependency-@reddit
Wait are you saying other fields don't have technical debt? Insane take, I can't believe it got 200 upvotes.
DingBat99999@reddit
So, many of the responses here don't seem to understand what technical debt is.
muntaxitome@reddit
Not really. If you are going to correct others why not do it correctly?
This is an article on Cunningham's own site: https://wiki.c2.com/?TechnicalDebt
Cunningham coined the term technical debt. What technical debt is, is a deliberate tradeoff you make with the intention of fixing it later. Hence the debt. What you describe is just shitty unmaintainable code. That could be technical debt but not necessarily.
originalchronoguy@reddit
Second bullet point is what most people consider tech debt. It is knowingly taking short-cuts with a some or a LOT of downside, risk for immediate gain. Those shortcuts can hamper re-write/re-factor in the future.
An example is doing a CRON job to poll stuff versus proper job queues. The CRON job is sloppy and not suitable for near real-time but if you need to synchronize files with rsync, it is "good enough" for the time being. Swapping it out for a proper queue is later forgotten and ignored because "good enough" doesn't justify the time the work when other priorities come in. So it is prioritized. And often never looked at until something major breaks or the sync takes too long.
SwordsAndElectrons@reddit
My experience working in a company that makes electromechanical capital medical devices:
Not many people use that phrase.
Every team has that problem.
jasonbutler@reddit
Hey, I just did a talk on this topic! Ended up being well received. https://www.youtube.com/watch?v=mKaTk70sRcI
rorychatt@reddit
TIL many experienced engineers still don't understand what tech debt is.
Tech Debt is a deliberate decision to trade one outcome, for another, on the basis that the increased friction/cost/effort ("the debt") is less than the benefits gained through that decision enabling sales/efficiencies/outcomes ("the thing you are purchasing with the debt").
Tech Debt is not a catch all term for poor choices that previous shitty engineers (myself usually) made that is causing pain today.
If somebody hasn't explicitly made the decision, it probably isn't tech debt.
RE: 'special term'. Every discipline has dumb terms. The dangly bits on overhead wiring on trains? It's called "Jewellery". How far a train wobbles? "kinematic envelope" Kanban came from Toyota in manufacturing.
forbiddenknowledg3@reddit
Wdym. It's just different in software. In software I'd say it's more extreme on both ends. We are able to hide some horrible technical debt, that the user never sees (other than a slowed down development cycle). On the flipside, we're able to refactor far quicker than 'real engineering' industries where they have fucked up roads, cars, aircrafts, that are simply too expensive to justify replacing.
DigThatData@reddit
Tech debt in Real Engineering is of the form "we made such and such decision a year ago, and now our options are heavily constrained because we're stuck with this now."
Concrete example: I used to volunteer at a fire department that was using an older generation of ambulances than the rest of the county because the garage doors were too narrow to fit the newer, larger trucks.
DazSchplotz@reddit
As current developer and former chemist: If you have technical debt in the real world, often people die. Or it just doesn't work at all. The rules of physics are much more unforgiving than compilers, interpreters and users.
muffl3d@reddit
I disagree though. Theory is different from practical applications. You can't have tech debt in theory but there's definitely tech debt in practical applications.
In other engineering, machines/systems are built with an understanding of how to make something. But that understanding changes over time and there's a new and better way of making that thing now. However you already invested a lot of money into a fully functional manufacturing chain of making said thing that is not practical to revamp and rearchitect. And that's what tech debt is.
I'd argue with that tech debt in traditional engineering has an even greater impact but we don't hear about it as much because the cost is too high and people accept that.
Abject-End-6070@reddit
That's kinda the same as mechanical/electromechanical stuff in automotive...but we are told to be agile with shit that can kil people.
nocondo4me@reddit
I would argue the older cars are easier to maintain than the newer ones.
ahrzal@reddit
They’ll also kill you a hell of a lot faster, too.
Crim91@reddit
efficiency
TopTraffic3192@reddit
Agree this is why people get away with releasing crap software.
The fallacy of agile is that it will prodce viable products. They dont tell you the story on how they scaled it witb re-engneering , refactoring abd dealing with the tech debt.
ub3rh4x0rz@reddit
Applied agile is just ripped off of lean which is how Toyota built cars better and cheaper than the competition so... I don't really buy your analysis. I look at it as, enshitification is a gas, and it will always fill whatever container it occupies, whether it's agile, waterfall, or any other methodology or set of principles.
I've seen agile done well and agile done horribly. Done well it's much closer to the manifesto and not SAFe or whatever other corrupted scrum bullshit people are doing.
Sunstorm84@reddit
A gas propelled out of C-Level mouths and propelled by PMs.
ub3rh4x0rz@reddit
I feel like you can judge how well a (larger) org does agile by watching the PMs. If they're mainly selling estimates to their bosses and/or pressuring engineers to underestimate, that's a sure sign the org sucks at it.
ILikeBubblyWater@reddit
"Real Engineering" https://www.youtube.com/@USCSB
Custom_Destiny@reddit
Anything made to imperial units is kind of like technical debt.
Any equipment whose supply chain for spare parts or fuel is deprecated and now requires ad hoc solutions is, effectively, technical debt. Think a gas furnace or the hydraulic elevator in your building.
Humdaak_9000@reddit (OP)
I don't understand why people who are bilingual are respected, but god forbid you work in two unit systems.
I was born in the US in the 1970s. I grew up bimetric. Most things, I prefer to use metric/si. Any sort of machine design or physics, I want to use metric. But there are certain domains where imperial works better. Carpentry is a good example: In metric, everything is divisible by 5 or 2. Imperial, being essentially base-12, gives you 1, 2, 3, 4, and 6. When you're working with hand-scale tools, this is a lot more pragmatic. The resolution of a good carpenter is ~3mm, or 1/8". Similarly, centigrade is how water feels. 0 is frozen and 100 is boiling. Fahrenheit is how humans feel: 0 is Fucking Cold and 100 is Uncomfortably Warm Anywhere You Don't Have A Tiki Drink In Hand. I'm a pragmatist. I have to use an absolute scale when doing physics anyway, so what is another units system or two? I also write python and C++ code. Use the right tool in the right domain.
Custom_Destiny@reddit
Ya ya I cook, imperial has its strengths, you’re right.
scodagama1@reddit
maybe you didn't explain it well enough?
tech debt is shortcuts we make to move faster, even if shorter road is sometimes bumpier, and sometimes leads through unknowns which end up taking longer time than taking a highway around
and sure, chemical engineer might not necessarily get why you would take a risky shortcut over proven highway, but it's all obvious when you realize that our industry is \~30-50 years old and most of the companies involved are in permanent state of race against others. It doesn't make sense to take reckless shortcuts if you develop a new fertilizer, but it makes perfect sense if you're in a race where often winner-takes-all
LawDear6289@reddit
F&$k the end users - be like rest of developers & push into prod.
Sunstorm84@reddit
Don’t hate the little guy.
LawDear6289@reddit
Ok
levelworm@reddit
Real world engineering has a ton of shits too.
OblongAndKneeless@reddit
Real engineering doesn't allow for huge mistakes because things will break and people will die. Computer programming allows for a limited number of "anomalies" before customers get pissed.
sraypole@reddit
Kinda like when Purdue ignored the addictive properties of OxyContin. That is tech debt in chemical engineering
Attila_22@reddit
Boeing says hi
Additional-Map-6256@reddit
Tech debt isn't just referring to bugs because you released imperfect code, it also exists in the form of using obsolete technology that no longer works well with newer infrastructure, security protocols, etc. The world of software moves at a significantly faster pace than chemistry, which obviously causes things to be out of date faster. It's not always important to update to the newest latest and greatest thing, but when you are working with something connected to the internet (or just other codebases written and updated by other people), you'll need to make updates.
GrandArmadillo6831@reddit
Just click release already, geez
hippydipster@reddit
Klingon code does not get "released". It escapes! Leaving a bloody trail of dismembered QA testers and cloud admins,
wwww4all@reddit
LOL, Tell your dad about Boeing and "Real Engineering".
Then show the car recall scene from the movie Fight Club.
SagansCandle@reddit
When you hack something, you understand that this will cause minor problems in the future.
Those minor problems accumulate, like interest on debt.
Eventually you lose more time with the accumulation of minor problems than it would have cost had you simply done it right in the first place.
Sometimes you can't afford to do it right - sometimes debt is necessary. That's rare, though. More often, it's just irresponsible. You don't always need to avoid incurring technical debt - just be aware when you're taking it on and that you're not taking on too much.
I don't see a parallel in chemical engineering, so I can understand why your dad shrugged. I still really like the term for software.
If you don't have time to do it right, you better have time do to it over.
originalchronoguy@reddit
In some cases, the product may have a very short shelf life. I work on things I know that is gonna retire in 6 months or a year. That I know for a fact, it will be disposed of once the vendor finished their roadmap on a feature to replace our interim solution. In those cases I don't want to spend 4 months on beta that will get retired in month 6.
SagansCandle@reddit
Totally agree. That's why there are so few silver bullets in software - everything's a little different. I think it's just a matter of being aware of these things so they're a part of the decision.
AdditionHaunting6019@reddit
True , most of the problems we face are there because of trying to find a working solution and not fixing the problem it self. We had some bad data coming intomour DB and a dev just stripped the spaces during ingress
hell_razer18@reddit
problem is normally we dont manage debt. I mean we care about the debt now but we never really make promise on like after release, we really should do this that because of this and that and this or that must be tied to speed of productivity or money related so other stakeholders started to care. normally debt is like closely tied to engineering only but say being able to centralize specific things so future integration can be faster, thats solving debt.
Some higher ups dont understand this concept though until it hits the user and they heard the complaint..
couchjitsu@reddit
I shared the idea of TDD with my dad who was an EE. He said they'd never do that because they have material waste when they throw away test hardware.
Tech debt exists because software is different than hardware, weapons (mechanical eng) and targets (civil eng)
Sensitive-Delay@reddit
The specific type of tech debt that comes from building the thing as fast as possible is not common in hardware, because the building phase is usually done by different people.
So you'll have an engineer design a part in CAD and it gets sent back because it is dumb.
Kind of like failing tests, but the tests are written by a person who did not write the code.
That would be awesome to have in software, but it would cost too much. Think of pair programming.
But of course, hardware has plenty of bugs and tech debt. Especially when trying new things or operating in new environments.
harrismillerdev@reddit
Technical Debt is a uniquely software concept. That doesn't exist in hardware
originalchronoguy@reddit
When you have "skin in the game" and where the results materially affects you, you will have a different perspective. When I was doing my solo thing; freelancing years ago, I was building things which I thought was high dollar -- creating a website for $125k that I would pocket. Timelines were given and you either had to meet it or not make that money. I also volunteered early in my career on equity. And again, shipping products determined if you can keep lights on.
Same with MVPs. MVPs are often built to test the market fit. Over engineering something that is going to be thrown away because the market simply rejected it. And that time-to-market often dictates if you get more money to finish the "market-fit" research and testing.
So when you personally have money you either put in, expect to get paid, it changes the outlook.
Teh_Original@reddit
These are still issues present in other forms of engineering, which OP is declaring to behave differently than software.
originalchronoguy@reddit
Technical Debt exists everywhere in any business or activity. You need to have an acceptable risk acceptance for those shortcuts. I know I need a new driveway for a rental. I could spend $15k for concrete driveway or $2k for gravel. I choose the gravel if it makes the place look hospitable to sell. What happens afterwards,is not my concern.
Those decisions are always based on risk-reward calculus.
im-a-guy-like-me@reddit
I dunno... Ya see stuff IRL that's real world engineering tech debt, but it's usually funny. They have regulations for anything that would be dangerous.
Aggressive_Ad_5454@reddit
We gotta stop calling it tech debt. The fat asses in the front office think they understand debt because they took accounting in biz school. To them it means they pay a little bit of interest and then just ignore it. Instead we should call it kludged-together systems with gaffer tape and Krazy glue.
DuffyBravo@reddit
In IT Leadership here. My job is to work with product so everyone understands what debt is OK to keep and what debt needs to be paid down. If you have Tech Debt issues in your Org it means you do not have good leaders.
aisingiorix@reddit
The crap that software engineers can get away with. And when something inevitably blows up, nobody faces any consequences, they walk away with a big severance and then get a new job somewhere else.