Hacker News Reader

Comment by 3pt14159 | Hacker News Reader

> just leads to more trouble down the road.

I used to lean that way, but these days I disagree. Sometimes it's worth it to bolt as fast as you can and don't look back to meet a deadline. It's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them.

I'm speaking as the guy that ended up writing most of those missing tests. You don't have a lead for long in some of these spaces and sometimes "strike hard and fast" beats "death in the tarpit of tech debt" in the medium run.

BUT.

YOU NEED TO PAY THAT TECH DEBT OFF AND MOST PEOPLE DON'T THEN THE BUSINESS FAILS ANYWAY.

Sorry for yelling, but that last part is easy to forget.

View on HN

It's also incredibly important for management to be able to communicate when a team is actually in one of those "200M vs 10M dollar" moments, and when its just like.. "well I sorta told a client we'd try and get this in by this arbitrary date I picked."

I've worked for too many managers where either everything, or too many things were urgent too frequently .. without any urgency gradient to differentiate.

> I've worked for too many managers where either everything, or too many things were urgent too frequently .. without any urgency gradient to differentiate.

Where I work, we affectionately refer to this as “the dumpster fire” of priorities. I’m lucky that we also work together to both recognize and rectify the dumpster fire blazing out of control.

No place I have ever worked had a "200M vs 10M dollar" moment. The mismanagers might whistle up a tune that sounded like it, but the bonuses vs no-bonuses only applied to the executives, never to anyone who actually wrote code.

The most offensive (to me) was a deadline that government regulations said was 3 years away (EFast2! Due 2009!). The mismanagers involved would not let us start working on meeting those requirements until less than 1 year remained. The product involved went from having 60% market share to under 25%. If they had not been purchased by a large conglomerate, they would have gone out of business from this. All the devs quit. The execs who created the crisis were fired. Some devs were rehired, about half would never go back no matter how much they were paid.

> it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them.

I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game.

Purposefully neglecting the safety of user data for "speed" like this should have your company taken away from you. Why can't adults stop behaving like toddlers?

> Why can't adults stop behaving like toddlers?

It certainly seems like a very successful strategy.

> > it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them.

> I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game.

There is a world of difference between “untested” and “insecure” API endpoints. What seems to have been cut in the example isn’t a permissions model, but some form of automated integration testing.

I’ve seen horribly insecure APIs with 100% code coverage, and I’ve personally burned myself on untested API endpoints where the privacy implementation was _too_ restrictive for what my customers were trying to do.

Ostensibly based on what I said, yes. But in reality, he was right that untested meant partially insecure. There are real costs to tech debt. But it's hard to argue against a giant raise.

two of our competitors have poor practice around endpoints that have opened their entire user database. What should we do?

Talk to your lawyers.

CYA by making sure you’re not making the same mistakes. Don’t try to be clever by exposing them.

Tell your clients that you apply best (/better) practice.

These are called kill points in sales.

For this kind of kill point however, you better make sure not just your own endpoints have cleanly passed scrutiny, but your entire modeling and process around them doesn’t produce insecure endpoints. Otherwise it is best not to let your sales team use such a kill point.

Tangential, but I always wondered why people don't have a separate class/struct/whatever that's actually used to send out. Might be overkill, but having a separate model to represent incoming request, out going requests, and the actual domain model makes me feel a bit more secure as to what's being sent out. It requires more work to update (adding fields to the outgoing models), but gives a bit of piece of mind.

We do this where I work. It's a lot of extra data types, but they're all extremely simple and better safe than sorry. As a rule, we don't send or receive actual domain objects in our APIs. It doesn't matter if they're currently "safe" - they might not be in the future.

I think the important thing here is that there's a clear and obvious reason that the deadline exists, with demonstrable costs for missing that deadline. I think a lot of people can get overly defensive about this because it's incredibly common for deadlines to exist primarily as an accountability / motivation mechanism - nothing really happens if the deadline isn't met, but to keep the team aligned we'll invent a deadline.

Which isn't really a problem in and of itself - but when that's used to justify crunch time, it can lead to taking shortcuts and making sacrifices with real costs that were wholly unnecessary, and it's a huge morale hit to be sacrificing your free time to work for essentially no reason.

100%. The difference between features and hygiene is that features have an end state. You can spend an infinite about of time improving code hygiene... and still have more to improve.

Real devs look for a good balance, and real management understands how to strike that balance in terms of priorities.

Terrible way to look at what may be a system, or at least a data structure, you can’t change in a few months. Things become critical and companies pivot.

Lots of teams build code bases with the idea they’ll rewrite and polish it later. This almost always, when it does happen which isn’t a lot over the short term, ends with having to work around the data model that our production data is dependent on and our customers.

Yes you can go in and translate old data models to new ones. You can add a transformer if that doesn’t work to set/get data. Yes you can redesign or you set of view components to account for a nicer frontend layout or data model. These are work around a to tech debt not a proper implementation.

But we could also be honest and admit that >75% of code we “write now and redo later” becomes business critical production code and never gets redone.

Reply on news.ycombinator.com