Hacker News Reader

Comment by edrxty | Hacker News Reader

Strong disagree on "technical debt"

Rather, the entire world is built on it and there's some level of acceptance required, but we definitely need a shorthand phrase for "we're doing something stupid that will save us time now and make us hate ourselves a year from now"

Edit: thinking on it, also "devops". It's really job title for "sysadmin but paid and owned by the software department to keep ITs fingers out of everyone's shit" but with a flashy name that sounds important so mgmt will agree to it. It's meaningless to us but it's a hyper-important industry term that saves us all a lot of suffering. It also must necessarily remain vague such that mgmt won't understand it and know to deny the posting. It's sorta like how snapchat used an obfuscated UI to keep parents out.

View on HN

> also "devops". It's really job title for "sysadmin but paid and owned by the software department to keep ITs fingers out of everyone's shit" but with a flashy name that sounds important so mgmt will agree to it

If that's what "devops" is now, sure, kill the term. Devop is not a job title, and I will die on that hill. The concept of DevOps is close collaboration between development and infrastructure teams throughout the development process, rather than throwing things over the wall and saying "that's infrastructure's problem now". Having a completely separate team entirely misses the point because it should be one team.

If that's what "devops" was before, we needed to kill the term earlier than you might think. Devops was originally a set of software release practises and culture that result in higher quality software, including high release cadence, blame-free postmortems, small patches, time for experimentation, automated testing, continuous integration, etc.

These practises normally require close collaboration between dev and infra, but are separate from it because you can have close collaboration on big, quarterly releases based on manually verified long-lived feature branches -- yet that is not devops.

The title/subtitle of the talk mentions both of these definitions: https://youtu.be/LdOe18KhtT4

I get where the author is coming from. The meaning of "DevOps" is in the name - it stems from a culture of encouraging _devs_ to do _ops_, and rejecting the antiquated separation between developers who write the code and the sys-admins who deploy the code.

The term "DevOps" doesn't need retiring, but "DevOps Engineer" does. DevOps is a culture and a practice that allows developers to iterate quickly by taking ownership of the operations of the software they build. Every engineer is a DevOps engineer. But such a widespread diffusion of responsibilities doesn't mean the specialists suddenly disappear. It's not like every dev knows how to configure a new multi-region cluster with automated failover. Instead, they know how to use whatever platform they've been empowered with to help them manage such operations.

For this reason, I think "Platform Engineer" is a better word than "DevOps Engineer" for describing the differentiated specialization of this role. Every developer in an organization engages in "DevOps" on a regular basis, whenever they debug a CI pipeline or deploy a new service. But someone needs to build, setup and maintain all the tooling to enable those _devs_ to do _ops_. In my mind, that's the specialized role of a Platform Engineer.

But DevOps does not mean "devs" doing "ops"! I feel like I'm repeating myself now, but devops is a culture promoting lean-inspired practises to reduce batch size and increase cadence. Go back to the original clique of people who started talking about devops and that was what they were discussing.

I can absolutely see how the name "devops" is confusing and easily lead to the sort of misunderstanding your comment propagates. I don't know why they picked that name. Maybe it was about applying concepts from operations research and business operations into development -- who knows.

Either way, the way I read your comment, it is more proof that the name is misleading and should be retired.

> If that's what "devops" is now, sure, kill the term. Devop is not a job title, and I will die on that hill.

I'm afraid you are already dead then...

This is the problem I suppose, that the definition is fuzzy. I'd say it's to have teams where "you build it; you run it" and so the dev and ops are done by one team. That means teams will produce things that are easy to operate, as they'll be doing it.

Related: a team claims to follow TDD but also has a test engineer whose job it is to write automated tests.

DevOps was what you meant, and still is in some places. But in reality it is either a fancy term of system admin, confined to cloud providers, or I don't know what I need but probably can do everything. You might be delighted by the terms DevSecOps as well, which is DevOps, with the confusing factor on steroids.

Or else "let's have the programmers do production support too, they're paid to much to get a full night's sleep".

Right, and "debt" is a beautiful word here. It accurately describes receiving the value today, but then owing that time back, with interest, in the future.

I'd argue that "debt" instills an unrelated meaning. As well as "legacy" and "debt" mean different things, yet may be related in some situations.

What is technical debt today might actually be (considered) no debt at all later on (or even from the beginning, in the extreme case you're building something for once only), for multiple reasons.

The context matters a lot, and begets a more elaborate discourse than just "that's technical debt", which in itself means little of the possible or mandated actions.

(edited to refine)

Tech debt is one of the few metaphors I love because it’s so accurate. What a lot of engineers struggle with is that manageable levels of debt is fine for a business and in fact superior to being cash constrained.

Some forms of debt are a headache if the business goes south but tech debt can be ignored if the software project goes nowhere. So the “terms” are good.

Rather than complaining about tech debt, one should communicate the advantages of paying it down or the risks of taking on too much. But the metaphor works and simply referring to “debt” will not dissuade people because a bit of debt is fine.

I agree, and I love the metaphor too, but you have to admit that something about the metaphor isn’t reaching peoples’ brains the way a good metaphor does.

A good litmus test here is to ask someone, “what if I told you that technical debt was originally a good thing?”... Like “Yes! Let’s go and get some technical debt, it will be great!” And so, can you understand why it might have started out that way?

People who really get the metaphor, can understand why it was originally a good thing to be desired. Because debt is a useful tool for the same reason, and if you can pursue what “being unable to take on technical debt” looks like, you can understand that it was a reaction to waterfall-style approaches.

But a solid 80-90% of people in tech don't understand how it could possibly be positive... “tech debt” is just a shorthand for the stuff that is causing development to go slower than you would have liked it to go.

The big difference between technical debt and actual debt in a money sense is that real debt is taken on consciously with an agreement betweenn debtor and lender. Because of this money debt can be worked into the planning and the risk can be calculated at the time the loan is initiated. Circumstances can change over time, but there is a bargain between the debtor and the lender. There are things like interest rates and collateral that are agreed upon when the debt is incurred.

Technical debt is by definition created to save time, so there is rarely an understanding of the risk that comes with the debt until the debt must be repaid. This means that the eventual payback can range from inconsequential to disasterous. The point is that the debtor won't know until it comes time to pay the debt back. Technical debt is often incurred in lieu of actual planning, not because a debtor is consciously and rationally weighing current reward against a future risk.

> People who really get the metaphor, can understand why it was originally a good thing to be desired. Because debt is a useful tool for the same reason

In that case, it is a very apt metaphor because most people naturally see debt as a bad thing. But with some nuanced thinking and deeper investigation you recognise that it can be useful sometimes.

I think they weren't saying that it's not an apt metaphor, but that it's not a good one, because now you first need to explain to people why regular debt is not necessarily bad, before being able to move on to your actual point that technical debt is also not necessarily bad.

Simply because it's a lot nicer to say than "my predecessor did dumb stuff". Especially when the predecessor is still around and outranks you.

The predecessor or old self did dumb stuff because of being pressured to deliver something quickly and had to cut corners. I don't see how he'd be offended that now it's time to go back and do it properly.

I think those who object to the metaphor do so because they interpret "technical debt" as "technical consumer debt". Consumer debt being a relatively benign form of debt, they don't believe it conveys the gravity of the matter at hand.

Consumer debt is mostly unsecured, almost perfectly fungible across term structures and refinanceable on a whim within a very competitive market of lenders. It's rare for it to be essential for a consumer to take on debt to continue to live[1] and there are typically safeguards in place to ensure consumers don't take on too much debt burden. The only debt that most consumers will come across that imposes any restrictions, or moves slowly, is a mortgage on a residential property. When we talk of "technical debt" we are talking of something has none of the nice properties of consumer debt. If I had sufficient cash I could pay off all my consumer debt within two minutes with a few taps of my phone screen.

On the other hand, I interpret "technical debt" to be akin to a complex structured financial product. Maybe there are convertability clauses between debt and equity, perhaps there is variability in the rates payable, or optionality that can be triggered by various real world events. This form of debt is not liquid, it is not refinanceable and it can be hard to find someone to take it off your hands for any amount of money! Nonetheless, sometimes it is essential for a business to take on this sort of debt to continue to thrive. That is an apt meaning for "technical debt" in my opinion.

[1] rarity depends on how socialised one's healthcare system is!

Except it doesn't. It's a one-sided and misleading concept.

The problem is usually finding a balance between "Let's hack some suicidally awful crap together quickly to see if we even have a market and then fix it when we have real income, except everyone knows we won't so it will be a permanent drag on the business" and "Let's build a beautiful extendable maintainable paragon of elegance and purity and ignore the fact that it'll take three years when we have six months of runway."

Too far in either direction will kill you. The sweet spot is between those extremes, and finding it is extremely difficult.

It's unhelpful that there isn't a word to describe aiming for that balance, never mind hitting it.

It's not one-sided though. Debt is often a very useful tool. You take on debt now because you can do more productive things with the money that will be worth more than the payments you have to make on it later. This is an extremely apt description of technical debt. Often times people will make bad decisions about what debt to take on, and the same is true for technical debt, and often times people will overestimate the value they'll get out of the debt, which is again true for technical debt, but debt is still a useful tool, and technical debt is a useful compromise you make to ship software.

Your description is apt when you are talking about an analogy between technical debt and personal debt.

For companies, whether to use debt or equity to finance their balance sheet is just a technical decision. Either way, you have to pay the cost of capital.

(Ie even if you finance your project from equity and not from debt, it still has to be better for your shareholders than just giving them the necessary capital back via a stock buyback.)

A company can have debt as a permanent feature of its balance sheet, just like equity.

Funny enough, I suspect from a corporate finance point of view, technical debt should actually be called 'technical equity', because technical debt only gets expensive when your project takes off. If you never end up using that piece of code, the technical debt never has to be paid. But it gets more and more expensive, the more successful your project is.

Just like selling 50% of your startup to an investor (as equity) gets more and more expensive (in retrospect), only if your startup really takes off. Debt stays the same price, whether your startup is middling or goes to the moon.

I get why Technical Equity is a better term, but very few % age of the population really understand what Equity means, while debt can be explained to a 5 year old

Yes. Though I wouldn't even say it's a 'better term'; just because the metaphor might hold slightly more water in some highly technical sense, doesn't actually make it a better term. ;)

This reminds me: if you went to a farm and actually 'picked the low hanging fruit first', they would likely fire you. The fruit higher up on the tree typically ripens faster, so should be picked first. (But the phrase as a metaphor is fine, and everyone knows what it's supposed to mean.)

How is debt not accurate here?

You wanna build something? You may over-invest (too much debt), invest just right (manageable debt) or wait until it's too late (the paragon you mention).

Debt is a nasty word and it's meant to be but like some other bad things if you know what you can manage you can come out on top. People take loans all the time because they want to achieve that sweet spot you mention.

Ah, thank you, this is actually the argument, not what the article said.

Unfortunately I've become a bit disillusioned that we can reclaim the conversation to be about the optimal level of quality, and what tradeoffs are acceptable.

Office bullshit language seems to have strangled nuance so hard that I'm now sure that most of these conversations are useless and we'd better spend our focus on finding and working with mature adults that don't need that much convincing

It's usually only a "beautiful extendable maintainable paragon of elegance and purity" in the eyes of the original architect. Everyone else sees it as leaking abstraction with bolts everywhere to keep the original idea somewhat working... Or just a massive pile of technical debt.

Code quantity is always dependent on how well the person making this judgment understands the software. While I'm sure that everyone will agree that there are some clearly better ways of doing things, they sure as hell won't all agree on what these clearly better ways are.

One person's pile of garbage is the next person's perfect implementation with easy to understand procedural logic.

Please take note that I'm explicitly not saying that any implementation is better then another. I'm just trying to convey that the term technical debt very much depends on the mindset of the person looking at the implementation

Take on lots of debt and you'll have a quick flash and then years of problems. Refuse to take on any debt ever and you may never get to university or buy a house.

Taking on debt is not inherently good or bad, it's context dependent.

I feel it maps to technical debt very well.

Not sure about that. A large part of the company (everybody close to money) probably see debt as a good thing because it lets them buy stuff. Of course you have to pay debt to creditors and how do they do it? By making more debt. It works well until you have to pay it off, all of it. So if they ever enter in a discussion about technical debt expect them to suggest to make more debt (and move faster.)

Building without foundations, driving blindfolded, etc, could be better metaphors everybody can agree upon. If you're talking with a CFO, talk about high leverage (as for derivatives.)

Why would you have to pay off all the (financial) debt?

Debt can be a permanent part of your company's capital structure just like equity can be a permanent part. Or do you have a plan to buy back all outstanding stock?

(Yes, real world debt in the form of bonds a due date, when you have to roll it over. But that's an accident of history. Instead companies could also sell perpetual bonds and put options on those bonds for the same effect.)

In finance terms, loosely speaking debt is the part of your capital structure whose cost is fixed in nominal terms. Equity gets the remainder of your income stream.

About high leverage: the more of your income stream you parcel out for fixed payments, the more you 'concentrate' your equity and the variability of the residual income it gets.

(Overall, I blame tax systems that give preferential treatment to debt over equity. Roughly, you can pay the capital cost of your debt with pre-tax money, but the capital cost of your equity comes out of post-tax money. Put them on equal footing, and you'll solve quite a few problems.)

I agree completely, it's a powerful concept, just too narrowly applied.

The 'technical' part points out that it's a special kind of debt, one that isn't measured directly in money. What's the debt? The debt is time.

You can't move some technical (which isn't a noun), or some money (which is), from one account to another, to pay down a time debt. You have to pay it off with skilled labor, which takes time in a way that isn't fungible with money: there's a lot of COBOL out there which can be lightly modified, or replaced, but that company can't find the hours of skilled labor to do more with it, at any price.

A codebase isn't the only time debt a company can incur, any process can be stuck in a suboptimal frame because no one wants to sign off on the time it would take to make it right.

I prefer "tech investment"! It's more positive ;)

> … "devops". It's really job title for "sysadmin …

Uhm, that what it has become, but not what it ought to be. I define the «DevOps» as an experienced software engineer with the black belt in networking and system administration. It almost never works the other way round, though, and ex-sysadmins who choose to transition into a DevOps role as an exit path from editing configs in vi, remain as cantankerous and unhelpful as ever before. From my own anecdotal and likely highly biased experience, I have encountered exactly one positive example of the reverse transition.

I’ve also found a lot of devops to be generally unhelpful and adversarial as well. They seem to forget the developer part of the job title and don’t help the developers deliver value to the customer. Instead some devops teams just break things unannounced, make sweeping changes that leave everyone unhappy, require unnecessary extra steps for simple procedures, and remain passive or negative.

I call those teams “developer obstructions” or DevObs for short.

Really this probably highlights the problem of having devops be it’s own role instead of a responsibility of a software team.

That resonates with my experience at large as well, which I find to be unfortunate.

I actually have come across a number of highly knowledgeable and talented sysadmins along the way, and I truly wanted the Dev part of DevOps to work and invested a lot of personal effort into trying to make it work although in vain each and every time.

Such individuals also have a tendency to create new, deeply entrenched silos that continue on to keep developers in shackles.

> I call those teams “developer obstructions” or DevObs for short.

With your permission, I will ecstatically add the new term into my daily professional vocabulary.

It’s very unfortunate! I don’t really know of a good solution other than stronger and more collaborative leadership preventing these “us vs them” silos. In effect the developers should be considered the customers of the devops team therefore they should be doing everything they can to aid the developers. Or, just have them in the sane team.

Yes definitely you can use it, credit would be nice though if the expression becomes well known ha ;)

DevOops

> "we're doing something stupid that will save us time now and make us hate ourselves a year from now"

Not to be pedantic but the metaphor is intended to speak to the economics of making short-term gains at the expense of long term savings. Developers need a way to communicate to business what cutting corners will cost them, financially. The concept of "technical debt" isn't perfect but it's a start. It speaks to the fact that if we don't adhere to engineering principles that allow for easy maintenance, expansion and extension then the company will pay the price when they want to engage in those endeavours.

If we're talking about these things in terms of "we hate ourselves" then we're having an emotional conversation. Unfortunately, that's all too common and it comes about because we didn't have these conversations in terms of dollars early enough. At that point you don't just have a technical debt problem, you have a morale problem. Engineers quit and people are brought in who don't understand the spaghetti coded system and end up exacerbating the problem because "we need to get this feature out before <insert arbitrary deadline that has some apparent meaning to the business>."

In Corporate and Enterprise environments, the term 'Technical Debt' is now commonly used for systems and platforms that are beyond their supportable lifecycle, but are still in use for reasons, yet need to be replaced as soon as possible. These systems were never just hacked together with the knowledge they'd be problem in the future.

Wouldn't "legacy" be a better word then? Meaning it wasn't meant to be a debt but it's still the legacy left to you today

Shouldn't those systems be named "legacy system" then?

You'd think so, yes. But... it's Corporate, nothing in those places makes much sense.

It's known now that they're a problem, and they're choosing right now to continue with that problem rather than spend the time/money/effort to change them. That's still technical debt. If it helps, you can see it as starting right now, rather than when the code was written. Either way, they're choosing to continue to have problems rather than pay off that debt... yet.

Strong disagree on your strong disagreement.

As the term has been corrupted, it just means "Code that isn't the way I would have done it."

You won't have to fix it a year from now -- you'll just be cursing at having to understand it.

And eventually, management will become convinced that everything has to be thrown out and rewritten; maybe it'll even be true.

> It's really job title for "sysadmin but paid and owned by the software department to keep ITs fingers out of everyone's shit"

Most devops aren't really fully-fledged sysadmins though.

The job of babysitting software and coming up with SLOs was always the part of system engineering that I hated. It wasn't digging through production outages with strace and tcpdump. They actually defined that as something that we didn't need any more so all DevOps gets is metrics and logs and they can't touch production at all and defined that job out of existence.

(Then every now and then I see some devops person pleading for information on how to deploy tools like tcpdump and strace to production and I can see that the technical foundation of devops is a pack of lies)

Also, devops is more "oh fuck they want to give all the devs a pager, quick hire some junior devs to give the pagers to and we'll call them devops".

(and now we're getting "Platform Engineer" which seems to mean "oh fuck those asshole system engineers were doing something productive before other than just being dicks about uptime and production access, how do we get them back?")

I think "technical debt" is a good metaphor, as long as you recall that taking on debt to fund investment can be a good idea sometimes. Debt isn't always bad in the long term.

It's arguably what makes it such a good metaphor.

In the video realm, Corp IT always came in and screwed up the production gear because they were so confused by the use cases. Instead, we started Production IT department. A corp IT sees a large array and wants to tune it to make lots of small random I/O, prod IT sets it up to make large continuous I/O. Prod IT sees a network port and plugs it into the corp network. Prod IT connects it to the isolated storage network, and doesn't even give the nodes access to corp network. Corp IT wants to install management software, Prod IT knows it'll only still resources from performance and doesn't bother.

If a corp IT and prod IT employee come in contact, a huge explosion occurs not quite as bad as matter/anti-matter. A healthy argument on best practices nontheless

The trouble with the term "technical debt" is that people tend to use it retroactively to describe messes which may not have been necessary or the result of an intentional technical choice.

It's uncomfortable to say, "In retrospect that was an unfortunate, unnecessary, and shortsighted choice that didn't really save any justifiable amount of time or money", so instead people say, "We've accumulated some technical debt" to cover up mistakes instead of acknowledging and learning from them.

The problem with tech dept is that it instills some kind of linearity -- you can pay it off whenever.

Often times "tech dept" comes from the fact that we do not truly know what to build. Hence we use the simplest measure to satisfy what requirements there are. Call it the "Occam's razor of software development".

Truth be told, because nobody knows anything, it's often easier to deal with an "Occam's razor" designed system that tried to stay simple; than with a prematurely overengineered mess.

Ah yes, sorry, I was unclear in my original comment.

Te point is to stick to the simplest implementation and don't try to reduce "tech dept" in favor of building premature optimizations.

I am very much for dropping the tech dept term

(https://www.madsbuch.com/assumptions/)

There are some differences between “tech debt” and “debt”:

Debt has to be serviced, and if it isn’t some asset is probably forfeited or you can be forced into bankruptcy. Not so for tech debt.

Debt is known for certain in a measurable quantity. Tech debt is not measurable and only exists to the extent people argue it exists. Two engineers may disagree in how much tech debt there is.

Debt can be used to fund things with a clear nexus. I borrow $1m to buy a house. Tech debt is taking on often unknowingly or even as a result of software dependency upgrades (or cloud) that turn debt-free into debted software silently.

There are probably plenty of other differences that make it a sort of half-applicable metaphor.

> Debt has to be serviced, and if it isn’t some asset is probably forfeited or you can be forced into bankruptcy. Not so for tech debt.

It is so for tech debt though. If you keep on accumulating it, at some point it's gonna have very negative effects: a ransomware incident, data leak or even a total company-wide standstill.

Say you have a product, and you add no new features (you fix some bugs and patch for security). The interest payments are a lot less than if you are actively developing new features and therefore adding complexity.

So it is dynamic in a way that normal debt isn’t.

It can be worse than debt or not as bad depending on the nature of the debt and its consequences.

If you have something written in OG Perl and and the messyness makes all your devs leave and you cant find anyone with skills that can be really bad! Although only if that product is your ownly source of revenue.

Say like many small companies trying to make it big you have “bread and butter” product A and “next gen unicorn” product B.

If B is far along and customers transitioning from A to B then tech debt on A is less expensive than if B is stalled and in a quagmire.

In the forward looking sense you are using it, sure. In the backward looking way it's usually used ("development on that is slow because it's full of technical debt") it usually 10% what you are talking about and 90% over engineering and stupid things that were done for no good reason at all where no one at the time was even thinking about the tradeoff for speed.

It's called a short-sighted decision.

It's a trade-off.

"engineering"

finally! A phrase so broad with so many applications that nobody will know what we're talking about!

Have you heard of Dynamic Programming?

The definition I have of DP is : "refactoring recursive algorithms into iterative ones by storing intermediate values (generally into arrays). It generally has performance gains due to avoiding redundant calls, at the cost of making algorithms less clear / readable "

At least that's pretty much what cs classes taught a few years ago

That seems pretty well-defined to me?

Oh, dynamic programming as a concept makes perfect sense and it's very useful and well-defined.

However the origin of the name is bonkers. See https://en.wikipedia.org/wiki/Dynamic_programming#History

> I spent the Fall quarter (of 1950) at RAND. My first task was to find a name for multistage decision processes. An interesting question is, "Where did the name, dynamic programming, come from?" The 1950s were not good years for mathematical research. We had a very interesting gentleman in Washington named Wilson. He was Secretary of Defense, and he actually had a pathological fear and hatred of the word "research". I’m not using the term lightly; I’m using it precisely. His face would suffuse, he would turn red, and he would get violent if people used the term research in his presence. You can imagine how he felt, then, about the term mathematical. The RAND Corporation was employed by the Air Force, and the Air Force had Wilson as its boss, essentially. Hence, I felt I had to do something to shield Wilson and the Air Force from the fact that I was really doing mathematics inside the RAND Corporation. What title, what name, could I choose? In the first place I was interested in planning, in decision making, in thinking. But planning, is not a good word for various reasons. I decided therefore to use the word "programming". I wanted to get across the idea that this was dynamic, this was multistage, this was time-varying. I thought, let's kill two birds with one stone. Let's take a word that has an absolutely precise meaning, namely dynamic, in the classical physical sense. It also has a very interesting property as an adjective, and that is it's impossible to use the word dynamic in a pejorative sense. Try thinking of some combination that will possibly give it a pejorative meaning. It's impossible. Thus, I thought dynamic programming was a good name. It was something not even a Congressman could object to. So I used it as an umbrella for my activities.

Providing value now for a user or customer which will need to be refactored later (iff the project continues) is not short sighted.

The job of a good engineer is to know which type of debt is good under the circumstances, and which debt is "toxic".

Precisely

You can make literally anything work with enough arduinos and duct tape, but should you?

It's only short-sighted if you don't plan to pay off the debt.

In reality, nobody ever pays it off until absolutely necessary.

> It's sorta like how snapchat used an obfuscated UI to keep parents out.

If anyone's else also confused about that part, there's some context: https://news.ycombinator.com/item?id=19022640

Having worked on projects drowning in technical debt, it's a very real concept.

It is a very real concept, but as a term it's no longer useful because the MBA's have heard it already. I don't look like a stereotypical programmer (tall white guy with good hair), so I hear what the "business owners" say when they think there are no programmer dorks in the room, and they passionately believe that "technical debt", "code quality" and "refactoring" are all scams that were made up to siphon money out of productive organizations (the article itself hints at a similar belief on the part of the author).

Hah. "The business" vs. the programmers. I hate that concept but it's something we must live with.

Well, remember, they think of it as management vs. (lowly, replaceable, necessary evil) "workers".

I like the term technical debt but people forget what debt is.

Everything has a cost. If the value added is more than the cost then it is not debt. Technical debt are areas where the costs exceed the value added.

Reply on news.ycombinator.com