9 ms·

I went through this. Not sure what toxic culture entails, but fucked up deadlines burned me out. Why do all software companies rush so hard.

by seivan 11y ago

fsloth 11y ago
" all software companies rush so hard." I suppose it depends on the business model the software is part of. If you want a pace that is compatible with proper engineering I would suggest looking into companies that deal with products whose lifetime is measured in decades such as CAD vendors or other highly technical software. All freshmen to software engineering have this weird idea that a piece of code can ship once it builds and just shipping as much code as much as possible is the best road to maximize productivity. Until they get hit in their faces time and again by recurring bugs and they start to understand that the way to manage long term software profitably is by making sure as few bugs as possible leave the software engineers desk, at which point best practices and long term planning starts to take hold. That's at least my view, YMMV to a large extent, probably.
- pjc50 11y ago
  just shipping as much code as much as possible is the best road to maximize productivity Just like juggling is a matter of throwing as many balls in the air as fast as possible ("What do you mean they come down again?")
  - ionforce 11y ago
    Disingenuous comparison is disingenuous.
    - pjc50 11y ago
      Well, it was more of a joke.
dexterdog 11y ago
Because to most project managers the problem always looks easier during the spec phase than it actually is. Very few people can groc the problem before doing it. Occasionally you over-estimate, but usually you are under. That's why a good manager of project managers usually just slaps a 25% increase on any estimate (adjusting for his knowledge of the particular PM's abilities).
- hnal943 11y ago
  Project managers should not be providing the estimates, but this comment works equally well for the developers who should be.
rdtsc 11y ago
There are 2 reasons: 1) Developers cannot reliably estimate software timelines. That often comes with experience and age, but many never learn that skill. It is a skill like programming itself. It comes with practice. 2) Break down in communication between management (product managers) and engineers who are writing code. On the first part. Usually junior software developers simply have not had experience shipping software in a full software cycle. From initial requirements, to design, to deployment, to maintenance. They did projects perhaps in school and homework exercises. Later some eventually learn that they chronically underestimate the time, and just start adding a factor (2x) to what their initial estimate is. That is a step up. But many never learn. There is also a race to the bottom -- the ones that promise shorter timelines get promoted and seen as smarter, more aggressive, better team players. The ones that are realistic are seen as maybe "taking it easy", "not working hard enough". Then everyone sees who gets promoted and show doesn't and learn -- "Aha I need to be like cool cowboy coder Joe over there, he is now running his own department". And so it spreads. Notice how there is often no feedback loop to punish the cool cowboy coder after the project is not delivered on time. On the second part -- even if there are engineers who know how to estimate the time, nobody asks them. Because the person who promised the feature already played golf with the customer and told them they'll get the new shiny toy in 6 months. That person might have never been a developer, they might have an MBA or where a football coach or something like that. And they usually have a higher position in the company. So they promise and then everyone is pushed to deliver on that deadline. If it fails the failure is usually attributed to the engineers doing the work because they haven't worked "hard enough".
- exelius 11y ago
  > 1) Developers cannot reliably estimate software timelines. That often comes with experience and age, but many never learn that skill. It is a skill like programming itself. It comes with practice. This is true. But this is the problem that Agile is supposed to help solve -- with the caveat that most companies don't do true Agile. I guess people are now calling it Continuous Delivery, but the idea is the same: you don't tell people when a feature will be done, only when you will be working on it. But even then, even with experienced estimators, the rule of thumb is to add 15-30% to their estimates. > 2) Break down in communication between management (product managers) and engineers who are writing code. Totally agree that this is very common. Unfortunately, the best way to solve this is with process, and developers hate process. But developers often don't realize that they can use the process to their advantage: a strong engineering lead can refuse to accept poorly defined requirements. That allows you to push back on product to force them to define the requirement better. IMO this breakdown is caused by just that: developers who say "oh yeah, I can do that", then start working on the problem and realize that there are a lot of undefined edge cases. If they promised it to the client in 6 months, fine, but define what "it" is. From the perspective of an MBA, if we have to bring in a contractor to implement it, fine. I know where I can go to hire certified rockstar contract developers at $200/hr, which I will do if the client is lucrative enough. There is no feature I can think of that would take more than 6 months of development.
benihana 11y ago
Not all software companies do. I work at a place that is very much "we'll ship it when it's ready" and some people here still feel burnout.

I went through this. Not sure what toxic culture entails, but fucked up deadlines burned me out. Why do all software companies rush so hard.

by seivan 11y ago

I went through this. Not sure what toxic culture entails, but fucked up deadlines burned me out. Why do all software companies rush so hard.

fsloth 11y ago

" all software companies rush so hard." I suppose it depends on the business model the software is part of. If you want a pace that is compatible with proper engineering I would suggest looking into companies that deal with products whose lifetime is measured in decades such as CAD vendors or other highly technical software. All freshmen to software engineering have this weird idea that a piece of code can ship once it builds and just shipping as much code as much as possible is the best road to maximize productivity. Until they get hit in their faces time and again by recurring bugs and they start to understand that the way to manage long term software profitably is by making sure as few bugs as possible leave the software engineers desk, at which point best practices and long term planning starts to take hold. That's at least my view, YMMV to a large extent, probably.

pjc50 11y ago
just shipping as much code as much as possible is the best road to maximize productivity Just like juggling is a matter of throwing as many balls in the air as fast as possible ("What do you mean they come down again?")
- ionforce 11y ago
  Disingenuous comparison is disingenuous.
  - pjc50 11y ago
    Well, it was more of a joke.

dexterdog 11y ago

Because to most project managers the problem always looks easier during the spec phase than it actually is. Very few people can groc the problem before doing it. Occasionally you over-estimate, but usually you are under. That's why a good manager of project managers usually just slaps a 25% increase on any estimate (adjusting for his knowledge of the particular PM's abilities).

hnal943 11y ago
Project managers should not be providing the estimates, but this comment works equally well for the developers who should be.

rdtsc 11y ago

There are 2 reasons: 1) Developers cannot reliably estimate software timelines. That often comes with experience and age, but many never learn that skill. It is a skill like programming itself. It comes with practice. 2) Break down in communication between management (product managers) and engineers who are writing code. On the first part. Usually junior software developers simply have not had experience shipping software in a full software cycle. From initial requirements, to design, to deployment, to maintenance. They did projects perhaps in school and homework exercises. Later some eventually learn that they chronically underestimate the time, and just start adding a factor (2x) to what their initial estimate is. That is a step up. But many never learn. There is also a race to the bottom -- the ones that promise shorter timelines get promoted and seen as smarter, more aggressive, better team players. The ones that are realistic are seen as maybe "taking it easy", "not working hard enough". Then everyone sees who gets promoted and show doesn't and learn -- "Aha I need to be like cool cowboy coder Joe over there, he is now running his own department". And so it spreads. Notice how there is often no feedback loop to punish the cool cowboy coder after the project is not delivered on time. On the second part -- even if there are engineers who know how to estimate the time, nobody asks them. Because the person who promised the feature already played golf with the customer and told them they'll get the new shiny toy in 6 months. That person might have never been a developer, they might have an MBA or where a football coach or something like that. And they usually have a higher position in the company. So they promise and then everyone is pushed to deliver on that deadline. If it fails the failure is usually attributed to the engineers doing the work because they haven't worked "hard enough".

exelius 11y ago
> 1) Developers cannot reliably estimate software timelines. That often comes with experience and age, but many never learn that skill. It is a skill like programming itself. It comes with practice. This is true. But this is the problem that Agile is supposed to help solve -- with the caveat that most companies don't do true Agile. I guess people are now calling it Continuous Delivery, but the idea is the same: you don't tell people when a feature will be done, only when you will be working on it. But even then, even with experienced estimators, the rule of thumb is to add 15-30% to their estimates. > 2) Break down in communication between management (product managers) and engineers who are writing code. Totally agree that this is very common. Unfortunately, the best way to solve this is with process, and developers hate process. But developers often don't realize that they can use the process to their advantage: a strong engineering lead can refuse to accept poorly defined requirements. That allows you to push back on product to force them to define the requirement better. IMO this breakdown is caused by just that: developers who say "oh yeah, I can do that", then start working on the problem and realize that there are a lot of undefined edge cases. If they promised it to the client in 6 months, fine, but define what "it" is. From the perspective of an MBA, if we have to bring in a contractor to implement it, fine. I know where I can go to hire certified rockstar contract developers at $200/hr, which I will do if the client is lucrative enough. There is no feature I can think of that would take more than 6 months of development.

benihana 11y ago

Not all software companies do. I work at a place that is very much "we'll ship it when it's ready" and some people here still feel burnout.