Hacker News Reader

Comment by fdsaasdf_999 | Hacker News Reader

> 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.

View on HN

> 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.

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.

Its only debt if it sticks around long enough to need to be dealt with.

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

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.

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.

> 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.

>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.

Perhaps it's the fact that you tolerated the technical debt that got you to google scale. I've seen a few projects where developers aim for (as swatcoder so eloquently put it above) the intellectual purity of clean systems and then watch these projects fail to be delivered.

We'd all like to be a filthy rich pragmatist but I wonder just how much the 'low-quality standards' enabled you to achieve that. Seriously, I would love to be a millionaire with regrets about low quality code instead of being broke with junior developers pointing out my code smells and technical debt.

Perhaps, but you can't determine whether a system is over or under-engineered a priori. Certainly not when you are racing a clock.

These kind of assertions are always after the fact. And in hind-sight I think we could've done a tad better.

I might be less-rich, but that's not even close to being broke. And the people I hire to clean up my technical debt would hate working here less.

Wow, that last paragraph is spot on. I found both your comments to not only be accurate and clear but also rather eloquent.

I've always felt we've misunderstood technical debt. It seems to be regarded as a problem with a lot of negativity surrounding it. Developers seem to fear being accused of introducing technical debt - like it's the worst kind of developer crime. But in reality, there is value in embracing it in early stage projects. As thinkingkong mentions below; 'Its only debt if it sticks around long enough to need to be dealt with.'

> 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?

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).

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.

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.)

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.

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.

Reply on news.ycombinator.com