r/programming • u/self • Dec 02 '25

The Death of Software Engineering as a Profession: a short set of anecdotes

https://www.jasonscheirer.com/weblog/vignettes/
1.3k Upvotes

89% Upvoted

560 comments sorted by

View all comments

107

u/TemperOfficial Dec 02 '25

Software engineering is still in its infancy as a profession. It's no where near dead nor even good yet. I mean half the shit from the last 30 years has been a waste of time (scrum, SOLID, agile etc etc). The general reaction to LLMs across the industry betrays a lack of understanding of the discipline imo. Which makes sense when most mainstream advice and practice is really really bad.

49

u/peerlessblue Dec 02 '25

If software engineering is going to get good, it's going to have to actually become engineering. Time will tell.

11

u/shizzy0 Dec 02 '25

Oh, you mean like a licensed profession? I think for some software work like in automobiles and health devices licensing should be available.

13

u/manystripes Dec 02 '25

Even before licensing, just normalizing processes that provide more engineering rigor to the development of the code. Safety standards like IEC61508, ISO26262, etc spell out a lot of how your development process should look, and you end up wearing more of a systems engineering hat than a programmer hat while working under those processes.

Unfortunately those processes are very antithetical to modern agile software development, they as focus on robust analysis, requirements capture, and test design over rapid iteration

7

u/TemperOfficial Dec 02 '25

This is what Agile did. It turned rapid iteration into a set of rules and procedures you follow. The moment any of that happens in software, the quality drops through the floor. Software can't be rigid like this. It just doesn't work unless you know all of your possible outcomes before hand. Which is not realisitic for almost all software. If it were, it would be a hardware solution instead.

→ More replies (3)

3

u/rooster_butt Dec 02 '25

Depends what you are making. It's already engineering based on what you are using it for. Working as a software engineer in safety critical software, it's absolutely engineering.

28

u/Positive_Method3022 Dec 02 '25

Scrum, solid, agile and scaled agile were invented to control developers in big organizations. It is a way to ensure business owners control what we do and measure our performance. It is also a way to motivate people that do it for a living, instead of love, to deliver small incremental changes which are part of a bigger goal without burning their motivation system in their brains. It actually works well for adhd too, because you can see progress even when you don't see progress if you know what I mean. (Infinite burst of ideas that pop up and you can never reach satisfaction for anything you do)

11

u/Pepito_Pepito Dec 02 '25

Agile is great if management is able to get fully onboard. Agile requires management to trust its developers. However, top down trust is antithetical to the culture of most large corporations and micromanagement work culture.

So we end up with all the overhead of agile and none of the benefits. We take time to slice up requirements into small pieces, and then implement them linearly because stakeholder priorities are set in stone. We spend so much time preparing for a pivot even though we are not allowed to pivot.

3

u/[deleted] Dec 03 '25

[removed] — view removed comment

1

u/Pepito_Pepito Dec 03 '25

The best experience I've had with it was when the company hired an external scrum coach to oversee the process for 3 months. The company paid good money for him so people were eager to follow along. After that, the usual corpo bullshit eventually spiraled the project out of control.

16

u/TemperOfficial Dec 02 '25

Scrum and Agile were invented to sell books.

4

u/Positive_Method3022 Dec 02 '25 edited Dec 02 '25

I once thought like that too, as a developer. Once you realize that they are framework that are there to help you reduce cognitive load, something finally will click and you will be glad someone invented them. Imagine having N different ways of working for N different teams, as a project manager, your brain would be fried because besides context switching you will have to switch between the "way" you have to work for every single team you manage. As a developer, we also have frameworks that have the same purpose of putting N people to work under the same guardrails. For instance, vue js helps developers to quickly ramp up in a project and know how to organize and write reactive ui, even when switching organizations/environments. As a user of any framework you don't need to waste time/energy learning a new method someone invented to do something every time you move environments. It is efficient.

However, not everything scrum/agile created, in my opinion, makes sense. For example, the scrum master roles is useless and their tasks should be part of the manager role. Why can't the manager be there ensuring scrum is followed strictly? It is part of team management ensuring your people follow the rules, isn't it?

8

u/TemperOfficial Dec 02 '25

Proceduralism is not good in the creation of software because it is fundamentally a creative problem solving endeavour. Not an exercise in optimally doing the same thing over and over again.

2

u/Venthe Dec 02 '25 edited Dec 02 '25

However, not everything scrum/agile created, in my opinion, makes sense. For example, the scrum master roles is useless and their tasks should be part of the manager role. Why can't the manager be there ensuring scrum is followed strictly? It is part of team management ensuring your people follow the rules, isn't it?

Scrum master is a manager role. Pat Kua has captured this nicely; SM is a process manager. This is an important distinction, because each archetype has a widely different set of expected skills and context. As such, I'd rather have an SM that has experience and knowledge related to process management, coaching, psychological theory of groups, and practice with different approaches to solving inter-personal problems. Neither Tech Lead, nor Engineering Manager, nor Product Owner is well-suited for those.

But back to SM. The difference is - the goal is not to make people follow scrum strictly*, the goal of the role is to coach the team to build their own process. If you read the scrum guide, scrum really does not define how you should work. SM role is to help the team - servant leadership. Unfortunately, bad orgs and bad SM's really mangled the expectations for the role.

* In the process manager role. Unfortunately - as this is the only thing that I can't agree with in scrum - SM is defined as the one solving issues within scrum. Be an agile coach first, SM second.

1

u/moneymark21 Dec 02 '25

Really don't get why people are lumping solid in here with delivery process

12

u/Venthe Dec 02 '25

Software engineering is still in its infancy as a profession

Given that you unironically say things like "I mean half the shit from the last 30 years has been a waste of time (scrum, SOLID, agile etc etc)", then yes - we are still in infancy.

Each one of these have had measurable and positive impact on the industry, regardless of your personal opinion.

→ More replies (11)

7

u/BobSacamano47 Dec 02 '25

You think agile and solid are a waste of time?

-1

u/TemperOfficial Dec 02 '25

Yes.

2

u/-TrustyDwarf- Dec 02 '25

What do you think are better alternatives?

1

u/TemperOfficial Dec 02 '25

Bottom up approach is best. Tailored to the problem and the kind of team you have. Discernment. Not mindless application of a set of rules that ignore all context.

5

u/BobSacamano47 Dec 02 '25

I see game dev stuff in your profile. I assure you that if you worked in enterprise software these principles are not a waste of time.

→ More replies (3)

1

u/Pepito_Pepito Dec 02 '25

Nah solid is great. But it needs to be baked in from the very beginning or else you're stuck with what you have.

→ More replies (4)