software engineering methodologies are simple, there's really only two goals

the first goal of a methodology is to make workers replaceable, and this is usually achieved by removing any worker agency in the project

the second goal of a methodology is to insulate decision makers from risk and this is usually achieved by blaming the workers for failure—for not hitting estimates forced upon them

unfortunately, "delivering software people want" doesn't make the cut

So much of my job is this over and over again on a loop:

"So what do you think we should do in order to responsibly build the Torment Nexus?"

"You can't. It's a Torment Nexus. Stop it."

"But the Torment Nexus is inevitable!"

"It's not. You could just not do it. You could stop right now."

ME: Hello computer! Please show me what I was doing recently

COMPUTER IN THE 1980's: l cease to exist when I am powered off. Please start whatever you were doing from scratch

COMPUTER IN THE 2000's: Yep here you go champ

COMPUTER IN THE 2020's: I stored 10,000 identical copies of what you were doing in 500 different global datacentres at a carbon footprint equivalent to leaving a semi-trailer idling 24/7 and also sent a copy to the FBI just to be safe. Let me know which one you want and I'll do my best to figure it out. By the way here are 10 things which are similar to what you were doing and 9 of them are ads. Do you like this? Please select "I love this very much" or "I'll be in love with this later" to continue

Last year I insisted my CS students stop using replit & learn to run their projects in python, java on their computers. They HATED it. I felt old fashioned, didactic. "This is just a company trying to get you hooked on their service, you all know how they throttle your virtual machines just to get you to sign up? That's a bad sign."

This year a couple of them thanked me for doing this in the hall the other day. "You were right, Mrs. Futurebird*"

I coud cry for joy.

*no they don't call me that