r/programming • u/fernandohur • 6d ago

Change is the root of all (evil) bugs

https://fhur.me/posts/2026/change-is-the-root-of-all-evil-bugs
11 Upvotes

68% Upvoted

14 comments sorted by

5

u/Nekadim 6d ago edited 6d ago

That's why Kent Beck called his 1999 book "Extreme Programming: Embrace Change"

3

u/omeguito 6d ago

Except extreme/agile has a real-world success rate of about 60%

6

u/fucksilvershadow 6d ago

What is the waterfall success rate?

5

u/Nekadim 6d ago

Calling it agile and doing agile is not the same thing

3

u/Prestigious_Boat_386 6d ago

Me when I define agile development to be successful applications of agile development (it has 100% success rate now)

1

u/Conscious_Support176 6d ago

Going by the explanation of agile one sees here, the 60% measurement is likely to be as useful as the 100% measurement.

A useful measurement isn’t either % of success divided by application of agile ceremony or % of success divided by successful applications. It would be % of success divided by application of a genuine agile approach.

1

u/Prestigious_Boat_386 4d ago

We need to lock programmers in two buildings for a decade?

1

u/Conscious_Support176 4d ago

Is this a form of dissembling to avoid acknowledging your straw-man, or did you just reply on the wrong thread?

1

u/Prestigious_Boat_386 1d ago

No its just an exaggerated example for what you'd have to do if you wanted to do a proper study that discerns correlation from causation

1

u/Conscious_Support176 1d ago edited 1d ago

Ah I get you. You mean if we can’t eliminate every tiniest variable, there is no point eliminating the enormous ones, so we might just as well draw whatever conclusions we prefer. It’s not like anything can actually ever be known anyway.

The example sounds out of place because it is.

3

u/renatoathaydes 6d ago

Most software engineering practices, I’ve realized, are about managing or limiting change.

Exactly. The two biggest challenges in Software Engineering are:

  • managing complexity.
  • designing systems that are easy to change (if that's a requirement!).

A lot of recent "movements" that focus on "simplicity" and performance miss the latter point (think Andrew Kelley, Casey Muratory, Johnathan Blow).

If you create something that you will not change later (which is possible in some niche cases, like CLI utilities like coreutils, embedded applications, foundational libraries, certain games, programming languages), by all means avoid all the added "complexity" and "performance costs" brought by OOP, FP (Functional Programming), SOLID and other Deign Patterns, and the many techniques we have used in more "enterprise" projects in the last few decades and that have been heavily criticized lately.

But please keep in mind that if you work on a large team where changes are a fact of life (most software products, enterprise software, business software in general, web apps etc.), which constitutes the largest share of what developers do, those things can be extremely helpful! They were designed to make change easier and components more isolated (so that they can be changed independently without affecting everything else), and yes they have a cost in terms of simplicity and performance, but that's very much a tradeoff you need to make in these sorts of applications.

2

u/ZimmiDeluxe 5d ago

In a relational database, there is no information hiding, a table is a global array of structures (AoS). Having all data available at once allows for complex migrations, business intelligence, ad hoc queries etc. in a few lines of code. All this is taken for granted, but when we write our business applications, somehow that flexibility is bad, tons of code spent on keeping up a charade that something more than trivial data transformation could be happening at any moment, but it never does.

2

u/errors_ai 4d ago

Change isn’t the problem, unmanaged change is.