Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> But not all tech debt is bad.

Of course not, if a company is profitable, its technical debt that made the company money and paid the bills. But if technical debt means running 40 servers instead of 10, then it should be something that is addressed, not ignored for 10+ years.

> but it was consistent in experience.

Consistent experience of being spammed by bot accounts. Looking at anyone popular and 95% of the replies are bots, or tweeting the wrong word and being spammed by bots. Is a terrible experience which has never been addressed.

> I think the greatest threat to musk is musk himself.

I agree. I think over the years popularity has gone to his head, stroked his ego, and he isn't the same person he was 10 years ago. He may not be the greatest example of a 'good' person but wqhat hes done with Tesla, SpaceX, etc, getting the right people in place and such to build these companies up, hes done well, but in the last 4-5 years hes sorta gone off the rails.



> But if technical debt means running 40 servers instead of 10, then it should be something that is addressed, not ignored for 10+ years.

Technical debt is rarely that simple. Usually it is a pile of Chesterton's Fences that only the people who built it really understand why its all there, but if you start just ripping it all down then you wind up breaking something important (think "service which scours databases to ensure that they're compliant with GDPR regulations and avoids a billion dollar fine from the EU" or something of that nature). The code may have grown organically and arguably need to be tossed and rewritten, but most of the time the code in its current state is also the requirements doc for the rewrite (and either the rewrite will take 10 times as long as anyone thinks or else the new system will throw away 90% of the old system without understanding it and now you have to deal with pissed off EU regulators and there goes everything you would have saved).

I'm usually on the side where I think its time to take the hard decisions and spend the effort either cleaning up the existing codebase or rewriting it, but that's rarely the way the business sees things, and they'd prefer to just bolt on some more crap yet again to keep it going for another year because they're trying to boost their metrics, not solve long term problems.


We could write a book on the different types of technical debt, obviously dumbing it down to 40 vs 10 servers is a massively over simplification on my part.

My point is when you're in a small company, even dollar counts, if infrastructure isn't trying to optimize hardware utialization then you end up throwing hardware at the problems. If engineering isn't trying to optimize codebases then you're throwing more resources at the problem (people, hardware, time, more services, monitoring, and safe guards). Then there's issues with marketing, sales, management, etc.

The other day we had that tweet from elon 'apologising' for android being slow and the '1000 requests' which was disputed by one of the engineers and he got himself fired.

But what he said is they have 10+ years of technical debt hindering performance.

Large companies like twitter suffer from the idea they are 'too big to fail'. They have 1000s of engineers and I question, what are they doing, you obviously have enough money and resources, but at the same time why are a portion of those people not sitting there optimizing what exists.

We don't see any resolution to bots, we don't see new useful features, we don't see any attempt to address issues people have been complaining about for 10 years. etc. So we have 1000s of engineers doing what exactly? There's some incredibly smart people working or worked at twitter, but their talents were wasted on effectively maintaining a sinking ship by trying to make it sink slower instead of trying to patch the holes and keep it afloat.


What’s missed in these discussions is that you need to get ROI out of the time spent working on code. If you spend all of your time rewriting code, your simply not going to get any ROI.

If a piece of code works and only needs changes once in a blue moon… well then it’s pretty good. Even if it’s a tangled mess of assembly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: