Comments by "" (@ContinuousDelivery) on "Types Of Technical Debt And How To Manage Them" video.

  1. Great story, thanks. Absolutely, I am a natural "improver rather than re-writer". The one caveat I have on this is my friend Martin Thompson, who I worked with for a few years doing some cool things. This is much better than me at knowing when to re-write and when to evolve. I nearly always evolve, and think it the less risky strategy.
    9
  2. I had a go at trying to suggest some ways of detecting competence: "20 Questions you should ask you next employer" https://youtu.be/2Afk9KVEgpE
    3
  3. I disagree, code is not really an asset. For example imagine two systems, that do exactly the same thing. Do you want the one that is 100 lines of code, or the one that is 100,000? More code is not better, so code isn't an asset. Software is a complicated idea, in some ways it is not really the code that matters, it is more about what you can do with it. Obviously you need some, and you need some code, and the quality of that code matters a lot, because it is quality that makes it work in the first place, makes it easy to change and improve, and makes it resilient in production and in the face of change. All these things matter in a real sense, and in some weird ways, I'd say that the quality of the code matters more than the code itself.
    2
  4. Glad it was helpful!
    2
  5. I think that dev teams need to own this, because Tech debt is contextual, but yes it needs to be budgeted for. The measures to avoid tech debt are already known - Stability & Throughput, the measures often referred to as the DORA metrics and described in the book Accelerate. https://amzn.to/2YYf5Z8
    2
  6. I think it makes the chances of code debt worse, but the consequences are probably lower, because the low-code solutions are usually a simplified version of what you could do, so the ways that you screw up are a bit simpler too. So "Bank Loans" rather than "Loan Sharks" on the whole.
    2
  7. The problem is that "Knuckles" has very limited tools at his disposal, and he often is on the board of most corporates. I was once in a meeting on a big project, hundreds of people, 10s of millions of dollars, it was a project that was going disastrously badly. We have been working 80+ hour weeks for many months, and after 18 months of development, the code didn't even all compile together. In this meeting some idiot senior manager said "It is time to 'bring the hammer down' and work harder". I confess I was rather unprofessional at this point, and called him a rude word.
    2
  8.  @timmartin325  Well that is a very unusual take I think. In general I think that what most people mean when we talk about manual vs automated, , and certainly what I mean, is that manual tests are interactively directed by a human, and automated tests execute without human intervention. So automated tests are accurately repeatable, and manual tests aren't.
    1
  9. Yes, I worked somewhere once that actively discouraged refactoring, I confess I was shocked, it's such a terrible idea.
    1
  10. I am not sure that entropy is a good analogy. Entropy just happens, it is not an act of will. Bit rot doesn't just happen, we do it AS and act of will. It happens when we are careless. Digital assets don't get worse on their own.
    1
  11.  @davidvernon3119  Sorry, but it doesn't happen at all if the software isn't changed. The bits that represented the system, still represent the system. So it is the act of people changing the software that causes the rot. So if we change how people undertake that change, so that it doesn't introduce the "rot" we can cure the effect of systems getting worse and worse. In fact, I was recently told by someone that still works on a system that I helped to create, that now, 15 years later, it is still the best system to work on that they have ever seen. Not saying that we did everything perfectly at the start, we didn't. But what we did get right, was that we established a dev culture that was good, and durable. So all of the people since have kept the code in a good state.  This is all about dev culture. There is nothing inherent in software that makes it rot, so we need better approaches to development and development teams to help them to avoid introducing the rot.
    1
  12. Yes, it is really all about the "interest" if you debt costs you, then it is a problem, if it is in some code that works, and is not changing, and so there is no cost to the debt, then it is probably not worth fixing.
    1
  13. Fundamentally you have to surface the "cost" of the debt. SRE can help with this, identifying service level indicators, and setting service level objectives, and error budgets. If you start to move outside of your "error budget", then everyone has already agreed that this is important, so it is obvious that you must work to get back on track.
    1
  14.  @doosrajawad  Thanks for the suggestion, I will add it to my list.
    1
  15. 👍 Thank you for your endorsement!
    1