4 ms·

While very occasionally useful I think technical debt issues mostly should not exist. Improving code quality should be considered part of any issue that a perso

• gravypod 7y ago
  The ticket serves as a communication point and a cost estimate tool. Even if the tasks are never explicitly assigned they are very useful. That's why I'd like a comment ticket linkage system. Support the positives of both usages by automating everything.
  • techbio 7y ago
    I could see this showing up in a near-future version of GitHub, along with enhanced default logging views.
• 0xEFF 7y ago
  In practice this results in too much time spent “cleaning up” and not enough time delivering business value. Hence why tech debt tickets are valuable, they allow the business to decide when to spend time on them.
  • sooheon 7y ago
    Yes, debts which need to be paid off immediately hardly serve their purpose.
  • karatestomp 7y ago
    It’s really hard to convey tech debt cost. Probably many systems have a ton of problems adding 5% to every feature here, 10% there, bad DB design from early in the project that makes a bunch of actions far riskier than they should be (but until it breaks several times no-one cares and if your devs are putting 3x as much effort into those dangerous operations and know what they’re doing, it won’t), and so on. Communicating that in a way the business folks will care about is hard, and the full costs are difficult to account for. [edit] hell, communicating that in a way the weaker end of technical managers will care about can be hard, for that matter. If they came up “doing it wrong” and are of a certain mindset, good friggin’ luck.
    • mlyle 7y ago
      People caring only a limited amount about technical debt is rational, arguably. Opportunity cost is high. And lots of organizations would be willing to borrow money at a usurious interest rate-- why not borrow technology for the same? ;)
    • hinkley 7y ago
      Never ask permission to do what has to be done. If they say no, and you do it anyway, then you are being insubordinate. If you don’t do it and then point to the decision as a reason why the project is failing, then you are right, but are a failure.
      • waheoo 7y ago
        And if you take too long to ship you're still a failure. I personally force stakeholders to define sunset dates on the system / code ill be writing. If its sunset date is never, cost of development proportional to roi approaches zero. If the sunset date is near, cost of development gets very, very expensive. Having that information both informs my priorities and the understanding of how long development will take / cost.
        • rileymat2 7y ago
          > If its sunset date is never, cost of development proportional to roi approaches zero. I am not sure that is good economics, because the discount rate for the future revenue approaches 100% over extended time.
          • waheoo 6y ago
            Does it? Not everything is monetarily cost based. Cant recreate a space probe 30 years ago to replace the one malfunctioning now. Cant recreate makret share gained against compeitors with stability problems. Interesting point though, definitely ignored it til now. Iguess the point is, everything is a trade off, and we shouldnt be acting like its either high quality or high throughput or high cost. Its somehwere in between and you get to choose depending on your contlstraints and needs.
  • deleted 7y ago
    [deleted]
  • cjfd 7y ago
    I don't really believe this although it seems rather hard to prove which side of this debate is right. Presumably it also depends on circumstances. I think any sort of messy or bad code immediately slows down developers. The truism that code is more often read than written comes to mind. This 'devivering business value' thing also sounds doubtful to me. Any sort of bad code is a breeding ground of bugs. So you have completed three stories this sprint and hence delivered three items of 'business value'? Sounds nice but it may not be so great if two of them are going to break in the near future because of code quality issues. In that case it maybe is just not true that three items of business value were delivered. In the context of bad coding practices it kind of becomes unknowable how many items of business value were delivered. I kind of despise the term 'technical debt'. It seems that in the beginning it was introduced to make the business side take code quality issues more seriously by likening them to something they could understand, i.e., debt, but now it seems to function as a way to postpone the fixing of issues, perhaps indefinitely. I think most things that go under the moniker of technical debt have an interest rate that is far higher than any business would enjoy taking out in terms of a loan. Let me give an example. Some code can be badly formatted. This hardly costs any time to correct but maybe it is also not worth it? Well, I once encountered some code that clearly was in the wrong function, so I asked the colleague who tends to know about that part of the application. Then it turned out it actually was not in the wrong function but instead there was no blank line between the two functions making me not notice that it was actually two function instead of one. In the mean time I had disturbed a colleague which also has a real cost in terms of getting back into whatever he was busy doing. All code quality issues have costs associated to them that are very difficult to know beforehand but I think the safer way is to always be improving code quality and that which is called the internal quality of software should actually just be maximalized and that technical debt most of the time has more costs than benefits and that the costs will come sooner than anyone expects, long before you MVP is actually finished so that you might actually have paid it off profitably beforehand.
    • jjeaff 7y ago
      Badly formatted code is hardly a true form of tech debt. Especially considering all the automatic tools like prettier out there today. Tech debt is getting a feature out there, asap by creating work around that normally would require some refactoring. In a lot of cases, it is forgoing optimization. We have several places in our app where we need to refactor some of our database tables in order to properly join the data and get it in an efficient manner. But that will take a few days of refactoring and testing so instead, we just query the missing data in a subquery 200 times or whatever. For now, it works fine, but as the dataset grows, that will obviously become slow and expensive. But by then, we will have more customers and more budget and hopefully more developers that we can afford to refactor that code. If we had unlimited time and resources, sure, go ahead and refactor your entire codebase every time you add a feature. You'll build an amazing company, assuming your customers pay you based on how awesome the source code is, rather than what it can do for them right now.
  • hinkley 7y ago
    It’s amortization, which tends to work pretty well from a scheduling standpoint. You don’t have to get everyone to “Make the change easy, then make the easy change.” Even a few people doing that can fight a lot of entropy. It’s enough if everyone makes the change easier, then makes the easier change. Every feature added to a section of code is new information about the shape of the project. Making better decisions as new information arrives is a perfectly reasonable way to stay between drowning in tech debt and deadlocked in over-engineering. YAGNI (yet) comes up so often I think it should just be YAGNIY. Also gets around the people who want nobody to ever enjoy their work by poo-pooing every single attempt at improvement.
  • closeparen 7y ago
    The business can and should set a general tone about where it wants to sit on the sloppy vs. perfectionist spectrum, but it's not competent to make those decisions at a granular level. That requires engineering sensibilities. We have a small but dedicated percentage of sprint bandwidth dedicated to engineering's internal priorities, off limits to PMs. It works decently well. Certainly better than letting PMs make calls on which modules are most in need of refactoring.
    • tln 7y ago
      Out of curiosity, what's the percentage? I do something like this approach too - Friday mornings I try to start with devops / tech debt / hacking instead of product priorities.
      • closeparen 7y ago
        It’s been between 15% and 30%. Some of that is just the treadmill of internal platform migrations though. 15% for local team’s own needs.