6 ms·

Reduce scope, or move the deadline. Taking shortcuts or working overtime in significant amounts just leads to more trouble down the road. Once the project is

Reduce scope, or move the deadline. Taking shortcuts or working overtime in significant amounts just leads to more trouble down the road. Once the project is delivered, make sure you all sit down and do a retrospective on what went wrong, decide what you’ll change next time, and actually make those changes. If none of this seems feasible in your organisation any time soon, leave. Don’t waste your time with people who aren’t taking your work seriously.

geocar 4y ago
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.
3pt14159 4y ago
> 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.
- bcrosby95 4y ago
  > 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?
  - Aeolun 4y ago
    > Why can't adults stop behaving like toddlers? It certainly seems like a very successful strategy.
  - djsweet 4y ago
    > > 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.
    - deleted 4y ago
      [deleted]
    - 3pt14159 4y ago
      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.
  - jacob_rezi 4y ago
    two of our competitors have poor practice around endpoints that have opened their entire user database. What should we do?
    - akiselev 4y ago
      Talk to your lawyers.
    - greggsy 4y ago
      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.
- ethbr0 4y ago
  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.
  - edgyquant 4y ago
    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.
- steveBK123 4y ago
  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.
  - bobwaycott 4y ago
    > 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.
  - Tangurena2 4y ago
    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.
- ryanbrunner 4y ago
  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.
just_boost_it 4y ago
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.
- Buttons840 4y ago
  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?
  - analog31 4y ago
    We don't. For instance throughout this thread, starting with the OP, there's a pretty clear consensus that it's management's fault.
    - edgyquant 4y ago
      Remember a lot of us are management ;)
HeyLaughingBoy 4y ago
> 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.
bartimus 4y ago
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.
- pojzon 4y ago
  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.
  - rblatz 4y ago
    Yes! Thanks for calling this out I see this mistake so often.
  - jacobr1 4y ago
    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.
roughly 4y ago
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.
ssss11 4y ago
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)
reckitralph 4y ago
This guy project manages

geocar 4y ago

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.

3pt14159 4y ago

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

bcrosby95 4y ago
> 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?
- Aeolun 4y ago
  > Why can't adults stop behaving like toddlers? It certainly seems like a very successful strategy.
- djsweet 4y ago
  > > 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.
  - deleted 4y ago
    [deleted]
  - 3pt14159 4y ago
    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.
- jacob_rezi 4y ago
  two of our competitors have poor practice around endpoints that have opened their entire user database. What should we do?
  - akiselev 4y ago
    Talk to your lawyers.
  - greggsy 4y ago
    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.
ethbr0 4y ago
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.
- edgyquant 4y ago
  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.
steveBK123 4y ago
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.
- bobwaycott 4y ago
  > 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.
- Tangurena2 4y ago
  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.
ryanbrunner 4y ago
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.

just_boost_it 4y ago

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.

Buttons840 4y ago
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?
- analog31 4y ago
  We don't. For instance throughout this thread, starting with the OP, there's a pretty clear consensus that it's management's fault.
  - edgyquant 4y ago
    Remember a lot of us are management ;)

HeyLaughingBoy 4y ago

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

bartimus 4y ago

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.

pojzon 4y ago
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.
- rblatz 4y ago
  Yes! Thanks for calling this out I see this mistake so often.
- jacobr1 4y ago
  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.

roughly 4y ago

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.

ssss11 4y ago

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)

reckitralph 4y ago

This guy project manages