Nithin

Posted on Aug 14

Finagle’s Fourth Law and BDD

#programming #architecture #softwareengineering #flutter

You think you’re fixing your app. You’re not. You’re just moving the bugs around. This is not a curse. It’s a feature. The sooner you accept it, the sooner you’ll stop pretending you’re smarter than entropy.

Finagle’s Fourth Law: Once a job is fouled up, anything done to improve it makes it worse.

1. The Law You Break Every Day

Fred Brooks said adding people to a late project makes it later. Finagle said any “improvement” to a broken thing creates new failure modes. You know this. You’ve seen it. You patch a leak, water comes out of the ceiling. You refactor your Flutter state management, and now the UI is stale. Welcome to reality.

2. Bug-Driven Development: The Only Honest Method

Forget “Test-Driven Development.” Forget “Clean Architecture.” Here’s the only process that works:

Fix the bug that hurts the most.
Accept that your fix will create new bugs.
Use those new bugs as clues.
Repeat.

You don’t need a perfect rewrite. You need controlled chaos. Perfection is a myth sold by consultants.

3. Stop Worshipping Patterns

Most teams treat Finagle’s Law as a warning: “Be careful!” They freeze. They design Bloc event/state machines that look like a PhD thesis. They map JSON:API to RFC 9457 with factories and adapters and mappers. They do nothing. BDD says: break things, but break them on purpose.

4. Controlled Breakage: JSON:API vs RFC 9457

If you’ve ever mapped API errors, you know the trap:

// JSON:API
{ "errors": [{ "status": "404", "detail": "Not found" }] }

// RFC 9457
{ "status": 404, "title": "Not Found" }

You want to support both error formats. You will fail. Here’s what you do:

Unify parsing for the format you use most.
When a bug appears in the other format, fix only that branch.
Notice the shared logic. Refactor only when you see it.

Stop pretending you can do everything at once.

5. Responsive Design: The Domino Effect

You scale your UI for tablets. Now buttons are billboards, labels overlap, tap targets are huge. BDD says:

Fix the chart label density.
When small phones get too few labels, extract breakpoint logic.
Let bugs show you where the real problems are.

6. Discipline or Disaster

Finagle + BDD is dangerous. You need discipline:

Keep fixes small. Roll back often.
Test critical paths: prices, rendering, error handling.
Avoid “quick fixes” with global variables and hidden timers.

Without discipline, you’re just firefighting. The goal is to let bugs guide you, not to live in chaos.

7. When Big Bang Rewrites Are Allowed

Sometimes, you need a big rewrite. Rarely.

Modules are isolated.
Technical debt blocks all progress.
Requirements change drastically.
You have strong tests.
The team is ready.

Example: Your monolithic Flutter app can’t handle dynamic modules. You migrate to plugins, write tests, isolate the migration. This is justified. Most rewrites are not.

8. The Final Rules

Small, surgical fixes. Big Bang rewrites are for gamblers.
Bugs are GPS markers. Follow them.
Architect last, refactor always.
Measure every fix. If things get worse, revert.

9. Why No Big Bang?

Big Bang rewrites break everything. Controlled fixes isolate issues, measure impact, and let you revert. Shrink the blast radius. Don’t gamble the system.

10. What Is a Fouled Up Job?

A job is “fouled up” when any change is risky. Complexity, technical debt, workarounds. In these cases, even good intentions create new bugs. BDD with Finagle’s Law accepts this. Bugs are signposts. Clean up in small, reversible steps.

Examples:

Integrating APIs: Add a small adapter for the new format. Keep the old one. Fix only what breaks.
Domain Layer Mess: Extract business logic for one feature. Use bugs to guide the next extraction.
Global State: Replace it in the worst widget first. Use new bugs to find the next target.

Bottom line:

Finagle’s Fourth Law is not a curse. It’s reality. Bug-Driven Development uses it as a compass. Don’t avoid making things worse. Make them worse in controlled ways, so you can make them better.

In Flutter, this means smaller migrations, isolated logic, and never believing a pattern will save you.

Entropy wins. You can only play along.

DEV Community