3 ms·

I used to think that the current setup of writing software, with prevalent scrum, talking-head managers, resume-driven development, byzantine tech stacks, drain

I used to think that the current setup of writing software, with prevalent scrum, talking-head managers, resume-driven development, byzantine tech stacks, draining practices such as heavy CI/CD and code reviews etc. is what makes the jobs unpleasant. But then I watched the documentary about the creation of the first Netscape web browser around 1995 or so, when they presumably didn't have any of the above. And yet, the interviewed people were still clearly on a verge of burnout. One of the developers said that she plans to quit the industry in her early thrities as she cannot imagine doing this for her whole life. So I guess the hard part is the task itself, not the circumstances.

dragonwriter 6y ago
> But then I watched the documentary about the creation of the first Netscape web browser around 1995 or so, when they presumably didn't have any of the above. Maybe not scrum and CI/CD stacks. Talking-head managers and various byzantine process decisions stemming from that and from management-resumé-driven decisions they did have; in fact, the agile movement was a reaction against that. CI/CD was a reaction against often heavy manual testing and endless bug hunting fromm bugs discovered far downstream (often, in prod) and the attendant pressures. Sure CI/CD may suck, but getting a ticket from support because the installer for your enterprise product with license cost starting at over $100K/year shipped to customers with a syntax error in the install script and the accompanying pressure from customers (and thus from sales, and thus from engineering management) that go with it isn't great, either. At least I imagine it wasn't for the dev team; when I experienced it in 1999 I was the support engineer who identified the problem...
- sumtechguy 6y ago
  Scrum and CI/CD helped with some of the issues. But created its own storm of them. However, we backfilled the time that stuff freed up with other things. Usually if scrum is failing is because of a lack of trust. Someone wants to know every detail of what is going on and will use the only process they have, scrum, to bash it out of you. They end up backing waterfall into scrum and thinking they are 'agile'. I am currently watching a perfectly functioning set of scrum teams being torn down due to a rethinking of what scrum is. Adding in 20-30 mins more work per story. Just to get the 'paperwork' right plus 4 different review processes before a story can be worked on. That does not sound bad until you realize the org is popping hundreds of stories every 2 weeks. Then toss in 'devops' where you have no responsibility to change anything but get all of the 'responsibility' of being yelled at because it is broken. Hanging out with a pager just incase something breaks. And it will, usually at 3am on a sunday and the tech support guys just call you without even opening the logs because that is what it says to do in their RTS guide. But it turns out you need the guys who wrote the code to look at it because they just checked in something 2 weeks ago and the whole thing just went O(N^N^N), and his phone is on mute. But you have no auth to check anything in or change the machines but the dev does.
deleted 6y ago
[deleted]

dragonwriter 6y ago

> But then I watched the documentary about the creation of the first Netscape web browser around 1995 or so, when they presumably didn't have any of the above. Maybe not scrum and CI/CD stacks. Talking-head managers and various byzantine process decisions stemming from that and from management-resumé-driven decisions they did have; in fact, the agile movement was a reaction against that. CI/CD was a reaction against often heavy manual testing and endless bug hunting fromm bugs discovered far downstream (often, in prod) and the attendant pressures. Sure CI/CD may suck, but getting a ticket from support because the installer for your enterprise product with license cost starting at over $100K/year shipped to customers with a syntax error in the install script and the accompanying pressure from customers (and thus from sales, and thus from engineering management) that go with it isn't great, either. At least I imagine it wasn't for the dev team; when I experienced it in 1999 I was the support engineer who identified the problem...

sumtechguy 6y ago
Scrum and CI/CD helped with some of the issues. But created its own storm of them. However, we backfilled the time that stuff freed up with other things. Usually if scrum is failing is because of a lack of trust. Someone wants to know every detail of what is going on and will use the only process they have, scrum, to bash it out of you. They end up backing waterfall into scrum and thinking they are 'agile'. I am currently watching a perfectly functioning set of scrum teams being torn down due to a rethinking of what scrum is. Adding in 20-30 mins more work per story. Just to get the 'paperwork' right plus 4 different review processes before a story can be worked on. That does not sound bad until you realize the org is popping hundreds of stories every 2 weeks. Then toss in 'devops' where you have no responsibility to change anything but get all of the 'responsibility' of being yelled at because it is broken. Hanging out with a pager just incase something breaks. And it will, usually at 3am on a sunday and the tech support guys just call you without even opening the logs because that is what it says to do in their RTS guide. But it turns out you need the guys who wrote the code to look at it because they just checked in something 2 weeks ago and the whole thing just went O(N^N^N), and his phone is on mute. But you have no auth to check anything in or change the machines but the dev does.

deleted 6y ago

[deleted]