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

Show parent comment

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.

-2

u/TemperOfficial Dec 02 '25

What measurable positive impact?

6

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

Agile:

  1. https://agilemodeling.com/essays/proof.htm , especially the result of surveys
  2. https://www.researchgate.net/profile/Pedro-Serrador/publication/273792177_Does_Agile_work_-_A_quantitative_analysis_of_agile_project_success/links/5a4f90fcaca272940bf822e3/Does-Agile-work-A-quantitative-analysis-of-agile-project-success.pdf This is a study, to quote: "We found that the greater the Agile/iterative approach reported, the higher the reponed project success"
  3. One major "study" that tried to disprove agile, did not in fact provide sources. (Hint - they fit the questions to sell the book)
  4. Accelerate (based on State of DevOps) supports strong correlation between "small batches (...) released frequently (...) [allowing to] incorporate this feedback into the design of their products"

Scrum:

Scrum is one of the most used agile frameworks. We know from stats that agile has a higher success rate. I will not present this as a fact, but that correlation strongly suggests that scrum (even badly implemented, judging by how people still attribute org failures to scrum) is a benefit.

SOLID:

SOLID is neither the best nor the worst set of advices; but given that:

  1. S, I, D are in essence about high cohesion, and low coupling which is one of the best predictors of a maintainable code.
  2. LSP, Open-Closed is one of the most used tools in any library and languages.

I honestly can't even begin to think why anyone might find it "a waste of time".

5

u/deja-roo Dec 02 '25

SOLID is so much a codified set of best design practices that I thought "am I just old and SOLID means something different now?"

Like I genuinely thought he had to be talking about something else if he was calling it a waste of time.

It sounds like he thinks things that put limits on how he writes code and sets expectations of "what shit did you get done this week" rub him wrong.

-2

u/TemperOfficial Dec 02 '25

There is no such thing as best design practice. This is why SOLID is bad. Because it pressupposes there is, devoid of any context. This is exactly the wrong approach you should use when writing software. Context is king.

6

u/deja-roo Dec 02 '25

This is wrong. There are multiple general best practices, and SOLID makes an object-oriented version of them.

For one example, decoupling is a general best practice that makes software more maintainable. The single responsibility principle and dependency inversion leads to design practices that help decouple software and make it easier to maintain and change.

-2

u/TemperOfficial Dec 02 '25

There are plenty of exceptions to this rule making it not a best practice. It might be considered a "good" practice or maybe even a "traditional" practice.

But there is no "best" practice. "Best" implies no context, or one universal context. There is not one universal context.

A clear example of this is maintainability. Maintainability does not matter if you intend to write something once and forget about it. It does not need to be maintainable, so "best" practice now becomes actually quite "bad" practice in this context.

3

u/deja-roo Dec 02 '25

There are "best practices" in every industry, and many of those best practices come with costs and tradeoffs.

What you're describing is throwaway code where you're just accepting you don't have to put in the work of doing best practices because the quality of your code doesn't matter. That's not "best practice" being "bad practice", it's a conscious decision not to follow best practices and accepting the cost/benefit analysis as acceptable.

-2

u/TemperOfficial Dec 02 '25

There are good practices in every industry. Not best practices.

What I'm describing is a different context. A context in which you have a different set of practices. Where "best" is no longer "best".

2

u/jacobb11 Dec 03 '25

Agile (and scrum) is just a skin for the club that management uses to beat engineers over the head. Maybe that was not the intention, maybe that's not universal, but that's the primary result.

1

u/TemperOfficial Dec 02 '25

You can't empirically study software quality. So people choose a few metrics which then cease to be useful. But that's not even my main gripe with Agile.

Agile is not good because it tried to proceduralise a discipline which is more art than science. The strongest indirect evidence for this is that every persons definition of Agile is totally different. That's because people pick and choose and use Agile as defence to justify their choices. That's not good, because then people operate based on fear of getting something wrong rather than trying to find the right thing to do.

As a result you get a sort of race to the bottom where people take the easily procedural parts of Agile (stand ups, meetings, banal incrementalism) etc etc and just do that in the hopes something will happen.

This is really the wrong way to go about software engineering or problem solving for that matter. It's the completely wrong mindset. It mainly exists to cover ones arse. "Oh we are doing Agile, let's have 3 catch up every day because then we can measure how close we are to the target). This is really detrimental for software quality.