Over the past few months, we’ve seen it happen again and again — teams moving fast, building apps, ticking boxes. But dig a little deeper and you’ll find the same thing lurking underneath: assumptions. Assumptions about what users want. About how processes work. About what “the business” really needs. And guess what? Assumptions don’t build good software — people do.
Author of the blog:
Harmjan Oonk
Over the past few months, I’ve noticed the same pattern popping up in several projects.
- We’re building new features.
- Working towards go-live.
- Creating amazing applications.
But when you start asking questions — really asking why (5 times why is a great method) , you sometimes discover an uncomfortable truth:
“This was a request from a BA, based on a process description.”
“That process was written based on assumptions.”
“Those assumptions came from earlier conversations.”
And there it is: assumptions.
As I always say:
Assumptions are the mother of all fck-ups*.
Even in low-code, where we can deliver insanely fast, these pitfalls still happen.
Even with bigger teams and excellent Business Analysts, we see this creeping in:
- We become a bit lazy.
- We take written requirements at face value.
- We trust what’s been passed on, without validating with the actual end-users.
And yet… we build software for those end-users.
Ironically, they’re often not involved in the process — too busy, too far removed, or simply overlooked.
My Takeaway:
- Don’t hide behind documentation.
- Don’t assume.
- Go out, talk to the business, ask the real
Because if we don’t, we risk delivering beautiful solutions… that no one actually wanted.