7 ms·

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 p

• bzxcvbn 4y ago
  It's called a short-sighted decision.
  • AeroNotix 4y ago
    It's a trade-off.
    • edrxty 4y ago
      "engineering"
      • bryanrasmussen 4y ago
        finally! A phrase so broad with so many applications that nobody will know what we're talking about!
        • eru 4y ago
          Have you heard of Dynamic Programming?
          • nephanth 4y ago
            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?
            • eru 4y ago
              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 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.
  • fnord123 4y ago
    Providing value now for a user or customer which will need to be refactored later (iff the project continues) is not short sighted.
  • papito 4y ago
    The job of a good engineer is to know which type of debt is good under the circumstances, and which debt is "toxic".
    • edrxty 4y ago
      Precisely You can make literally anything work with enough arduinos and duct tape, but should you?
  • xboxnolifes 4y ago
    It's only short-sighted if you don't plan to pay off the debt.
    • xigoi 4y ago
      In reality, nobody ever pays it off until absolutely necessary.
• ghayes 4y ago
  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.
  • Juliate 4y ago
    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)
  • drewrv 4y ago
    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.
    • crdrost 4y ago
      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.
• madsbuch 4y ago
  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".
  • eru 4y ago
    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.
    • madsbuch 4y ago
      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/ https://www.madsbuch.com/assumptions/)
• Jaruzel 4y ago
  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.
  • darkwater 4y ago
    Shouldn't those systems be named "legacy system" then?
    • Jaruzel 4y ago
      You'd think so, yes. But... it's Corporate, nothing in those places makes much sense.
  • eric-burel 4y ago
    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
  • wccrawford 4y ago
    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.
• helpfulmandrill 4y ago
  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.
  • olalonde 4y ago
    It's arguably what makes it such a good metaphor.
• jon-wood 4y ago
  > 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.
  • kqr 4y ago
    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.
    • zeckalpha 4y ago
      The title/subtitle of the talk mentions both of these definitions: https://youtu.be/LdOe18KhtT4 https://youtu.be/LdOe18KhtT4
    • chatmasta 4y ago
      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.
• fallingknife 4y ago
  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.
• dub 4y ago
  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.
• quickthrower2 4y ago
  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.
  • Avamander 4y ago
    > 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.
    • quickthrower2 4y ago
      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.
• Toreno96 4y ago
  > 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 https://news.ycombinator.com/item?id=19022640
• inkyoto 4y ago
  > … "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.
  • lloydatkinson 4y ago
    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.
    • inkyoto 4y ago
      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.
      • lloydatkinson 4y ago
        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 ;)
• gspencley 4y ago
  > "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>."
• JJMcJ 4y ago
  Having worked on projects drowning in technical debt, it's a very real concept.
  • commandlinefan 4y ago
    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).
    • JJMcJ 4y ago
      Hah. "The business" vs. the programmers. I hate that concept but it's something we must live with.
      • commandlinefan 4y ago
        Well, remember, they think of it as management vs. (lowly, replaceable, necessary evil) "workers".
• dylan604 4y ago
  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
• UIUC_06 4y ago
  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.
• lamontcg 4y ago
  > 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".
  • lamontcg 4y ago
    (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?")
• 2OEH8eoCRo0 4y ago
  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.