4 ms·

> The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges. A

> The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges. And that is the wrong problem that too many software engineering teams solve. Let's not solve a customer problem, let's solve the problem of solving customer problems and hopefully in year or so we'll get to that. Iteration speed is an issue for hardware. It becomes an issue for software teams when too much time is spent tooling, generalizing and reinventing wheels. I point that out because this sort of example pushes the wrong buttons for many software engineers, including myself. We don't need more time spent on meta-problem solving. Much less, in fact.

ukj 7y ago
That depends on whether you see technical debt accrual as a 'meta problem'. The faster you iterate without thinking long-term - the faster it accrues. 20/20 hindsight and all that.
- thinkingkong 7y ago
  Its only debt if it sticks around long enough to need to be dealt with.
  - ukj 7y ago
    Short-term thinking is a form of technical debt. How important of a problem are you really solving if the solution is not meant to "stick around"? https://en.wikipedia.org/wiki/Time_preference https://en.wikipedia.org/wiki/Time_preference
- swatcoder 7y ago
  Technical debt is not any sort of problem in and of itself. It can be accrued naively, which is an antipattern, but when that isn’t the case technical debt is a vehicle for leverage. You get more value from less work. With all development efforts having a finite lifetime, and many having a particularly short one, wise exercise of technical debt becomes an essential skill for both project managers and developers. Vilifying technical debt, and even prematurely mitigating it, are just as naive as inadvertently introducing it.
  - ukj 7y ago
    Nothing ever is a problem 'in and of it self'. This kind of vacuous 'thinking' is not what I am talking about. Holistically, if your system is meant to endure the test of time (think Google-scale), more technical debt is worse than less technical debt.
    - swatcoder 7y ago
      > if your system is meant to endure the test of time (think Google-scale) While some exceedingly few products have that destiny, it’s precisely the naive bias towards thinking that your project does that leads to wasteful over-engineering. Products and projects are not the same thing. Most of the Google-scale products that you see leveraged tons of technical debt on projects along the way, some critically valuable and some certainly wasteful. If you’re adding a feature to one of these products that are already at that scale, then your attitude toward technical debt will be different. But effectively nobody reading this thread is doing that, and the few that are know who they are. Most readers here are working on projects with near-term deadlines and development lifetimes measured in a few months or years. As much as judicious exercise of technical debt enables those projects to deliver on their requirements more quickly and for less cost, more is better. Many of us come into the industry thinking otherwise because we’re drawn to the intellectual purity of clean systems, but that purity just isn’t what actually matters most of the time. It can take a while to accept and internalize that.
      - username90 7y ago
        > If you’re adding a feature to one of these products that are already at that scale, then your attitude toward technical debt will be different. > But effectively nobody reading this thread is doing that, and the few that are know who they are. Aren't a large fraction of HN readers working at Google or similar companies?
      - ukj 7y ago
        >Nobody reading this thread is doing that, and the few that are know who they are. That's the false dichotomy which earned me my stripes. I used to think I am the former guy, then I realised I am the latter guy. The only thing that changed is that some time passed. The hind-sight of my mistaken identity is that the systems I have been working on for 15 years became less, not more maintainable as a result of tolerating technical debt. They also became Google-scale (which is what we were hoping for, but didn't believe at first). I am the furthest thing from a purist. I am a filthy rich pragmatist who regrets having low-quality standards.
- collyw 7y ago
  This article rings very true for me at my current company, the tech lead is always off to add more fancy new tech to the stack, and we still manage to accumulate a ton of tech debt. Adding a load of automated tests is the first thing we need to do start being able to iterate more quickly. (I view this as both paying down technical debt and solving the right problem). Thankfully that was discussed just the other day in our tech debt meeting (while the tech lead was saying how we need to add a Neo4j database, a Leucene search index and remote procedure calls - he had read an article saying how that is cool again).
worldsayshi 7y ago
I think there's often a sort of cargo cult ay work here. We spend so much time trying to solve the meta problem, how do we get better at solving any problem faster. But very little time trying to find out what is actually the original problem. That problem falls between the chairs of responsibility.
psychoslave 7y ago
That doesn't seem the point of the article. Whether through the dumbest monolithic code or with the finest higher order algebra abstractions, the point seems to diminish the feedback loop with your target and come to such a dynamic as soon as possible.
z3t4 7y ago
> Let's not solve a customer problem, let's solve the problem of solving customer problems That's exactly what causes too much time spent on tooling and reinventing wheels. Not that tooling is bad, but often you spend two weeks in order to save one hour. And that is the best case scenario, where the extra complexity usually will slow down future development - rather then make it faster. In the article MacCready strategy was fast iteration, rather then focusing of safety and engineering. Basically the "go fast and break things" motto.
amelius 7y ago
I think the article doesn't apply when the problem is simple. Imagine you have to build a word processor in assembly language. At that point it may be worth it to build a compiler first.
- kragen 7y ago
  Depends on the situation. WordStar, written in assembly language, was better than any word processor written in higher-level languages for the same computers (say, a 2 MHz Z80 with 48 KiB of RAM); perhaps in part this is because Turbo Pascal didn't exist for several years, but even when it did, code written in assembly was still dramatically smaller and faster, and that mattered a lot. (Turbo Pascal was itself written in assembly language.)

ukj 7y ago

That depends on whether you see technical debt accrual as a 'meta problem'. The faster you iterate without thinking long-term - the faster it accrues. 20/20 hindsight and all that.

thinkingkong 7y ago
Its only debt if it sticks around long enough to need to be dealt with.
- ukj 7y ago
  Short-term thinking is a form of technical debt. How important of a problem are you really solving if the solution is not meant to "stick around"? https://en.wikipedia.org/wiki/Time_preference https://en.wikipedia.org/wiki/Time_preference
swatcoder 7y ago
Technical debt is not any sort of problem in and of itself. It can be accrued naively, which is an antipattern, but when that isn’t the case technical debt is a vehicle for leverage. You get more value from less work. With all development efforts having a finite lifetime, and many having a particularly short one, wise exercise of technical debt becomes an essential skill for both project managers and developers. Vilifying technical debt, and even prematurely mitigating it, are just as naive as inadvertently introducing it.
- ukj 7y ago
  Nothing ever is a problem 'in and of it self'. This kind of vacuous 'thinking' is not what I am talking about. Holistically, if your system is meant to endure the test of time (think Google-scale), more technical debt is worse than less technical debt.
  - swatcoder 7y ago
    > if your system is meant to endure the test of time (think Google-scale) While some exceedingly few products have that destiny, it’s precisely the naive bias towards thinking that your project does that leads to wasteful over-engineering. Products and projects are not the same thing. Most of the Google-scale products that you see leveraged tons of technical debt on projects along the way, some critically valuable and some certainly wasteful. If you’re adding a feature to one of these products that are already at that scale, then your attitude toward technical debt will be different. But effectively nobody reading this thread is doing that, and the few that are know who they are. Most readers here are working on projects with near-term deadlines and development lifetimes measured in a few months or years. As much as judicious exercise of technical debt enables those projects to deliver on their requirements more quickly and for less cost, more is better. Many of us come into the industry thinking otherwise because we’re drawn to the intellectual purity of clean systems, but that purity just isn’t what actually matters most of the time. It can take a while to accept and internalize that.
    - username90 7y ago
      > If you’re adding a feature to one of these products that are already at that scale, then your attitude toward technical debt will be different. > But effectively nobody reading this thread is doing that, and the few that are know who they are. Aren't a large fraction of HN readers working at Google or similar companies?
    - ukj 7y ago
      >Nobody reading this thread is doing that, and the few that are know who they are. That's the false dichotomy which earned me my stripes. I used to think I am the former guy, then I realised I am the latter guy. The only thing that changed is that some time passed. The hind-sight of my mistaken identity is that the systems I have been working on for 15 years became less, not more maintainable as a result of tolerating technical debt. They also became Google-scale (which is what we were hoping for, but didn't believe at first). I am the furthest thing from a purist. I am a filthy rich pragmatist who regrets having low-quality standards.
collyw 7y ago
This article rings very true for me at my current company, the tech lead is always off to add more fancy new tech to the stack, and we still manage to accumulate a ton of tech debt. Adding a load of automated tests is the first thing we need to do start being able to iterate more quickly. (I view this as both paying down technical debt and solving the right problem). Thankfully that was discussed just the other day in our tech debt meeting (while the tech lead was saying how we need to add a Neo4j database, a Leucene search index and remote procedure calls - he had read an article saying how that is cool again).

worldsayshi 7y ago

I think there's often a sort of cargo cult ay work here. We spend so much time trying to solve the meta problem, how do we get better at solving any problem faster. But very little time trying to find out what is actually the original problem. That problem falls between the chairs of responsibility.

psychoslave 7y ago

That doesn't seem the point of the article. Whether through the dumbest monolithic code or with the finest higher order algebra abstractions, the point seems to diminish the feedback loop with your target and come to such a dynamic as soon as possible.

z3t4 7y ago

> Let's not solve a customer problem, let's solve the problem of solving customer problems That's exactly what causes too much time spent on tooling and reinventing wheels. Not that tooling is bad, but often you spend two weeks in order to save one hour. And that is the best case scenario, where the extra complexity usually will slow down future development - rather then make it faster. In the article MacCready strategy was fast iteration, rather then focusing of safety and engineering. Basically the "go fast and break things" motto.

amelius 7y ago

I think the article doesn't apply when the problem is simple. Imagine you have to build a word processor in assembly language. At that point it may be worth it to build a compiler first.

kragen 7y ago
Depends on the situation. WordStar, written in assembly language, was better than any word processor written in higher-level languages for the same computers (say, a 2 MHz Z80 with 48 KiB of RAM); perhaps in part this is because Turbo Pascal didn't exist for several years, but even when it did, code written in assembly was still dramatically smaller and faster, and that mattered a lot. (Turbo Pascal was itself written in assembly language.)