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

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.

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.

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

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

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

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.

Talk to your lawyers.

> Why can't adults stop behaving like toddlers?

It certainly seems like a very successful strategy.

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.

My motto for these situation is, if it doesn't fit, cut it. Pushing deadlines back looks sloppy, and I take enough pride in my work that I want to take the time to make a quality product. I can always go back and add features later if they're important. I don't know much about American football, but I know most of the game is making plays to move a few yards. You basically keep pushing until the opportunity comes to make a pass that gets you to the end zone, and you need to keep make good plays so you don't turn over the ball. That's what software development feels like to me, pushing quality improvements to keep making yards until eventually you're in a position where you're one project away from shipping something big.

I like this analogy. A lot of time leaders get in a tough 4th-down situation, where they must make a big play, and so they tell the players to make the big play. If the players fail, that's the players fault, the coach will yell at them and that's that; right? Well, no. If a coach acted like that they'd be fired, so why do we accept the same from our business leaders?

We don't. For instance throughout this thread, starting with the OP, there's a pretty clear consensus that it's management's fault.

Remember a lot of us are management ;)

Someone I worked with noted there were two types of projects - projects that needed to be done by a date, and projects that needed to be done to a spec. Figuring out which one you're working on is the key - need to release by Christmas? Great, figure out what you can deliver by then and deliver it. Need to meet a compliance target? Great, figure out how long it's going to take.

It's true. But often that scope isn't properly defined. So you get a fixed timebox, a fixed "scope" (product has to be finnished) and a scope that's unclear. So first make sure the scope is properly defined. There's the current state and the desired state. There should exist a list of the business requirements that aren't covered by the current state.

Second make sure that list of business requirements is actually a list of business requirements. Often I see clients coming with lists of missing functionalities (e.g. a list with the desired functional design = waterfall). It's nice that clients come up with their suggestions on how things could be implemented. But these should not be set in stone and always come accompanied with the actual business requirements. If the business requirements are unknown the team will be unable to know if certain things might be covered in other ways. Or come up with alternative/reduced solutions to get them covered more quickly.

What you described is a waterfall.

If you want to deliver quality stuff, you have to iterate fast a ask for feedback.

They screwed up be ause they spent too much time on the initial phase. During that time they should have already prepared few PoCs that could transform into MVP by now.

Also customer feedback usually trumps top-down opinions even when operating in a waterfall model. I've rescued a few "ScrumFall" projects by just ignoring sunk-costs and seeing how fast you can iterate to an MVP from what you have. If you real customers that find value in the smaller scope project - it trumps the political battle around what the scope really should be and buys you credibility to adjust timelines and iterate more in the future.

Yes! Thanks for calling this out I see this mistake so often.

This. Everything this.

There are great managers out there, who will take your job seriously, and who can amplify the value you create together, and there are “managers” who know only the whip. If you only know the latter, keep looking because you deserve better.

> Reduce scope, or move the deadline

IMO, this is the only correct answer. Unless you're in a "lose the company" situation, burning out the developers will only make things worse.

This ^ we usually rebaseline the schedule and deliver later.

I usually try to get the execs (sponsor, exec committee etc) to understand the difference between a hard and soft deadline. Hard being “it must be actioned” by a date such as a regulatory change, a construction project etc, and a soft deadline being “we want to do x by y” where the impact of delays is less.. perhaps worst case some revenue isn’t realised.

Perhaps trying to help solve the current project management approach issues would help you improve the workplace without having to leave (and would help all of your colleagues too it seems)

This guy project manages