Don't expect requirements that will "never change, guaranteed" to actually "never change, guaranteed"

I just want them to not change while I'm building the god damned thing.

@sariel don't even think about it...

My favourite is:

Them: We need this over complicated, insane process to make life easier for us.

Us: Deliverers this thing after months of consult and rework.

Them: We hate this thing, it made our life's harder because we now have to do our jobs.

Let's remove it and do this other complicated and manual thing we used to do instead.

Us: 🪦

@sariel no. They should better change before you've built everything and have to rebuild it yet again.

@iiii small requirements are ok to change. Large requirements that change architecture are not.

It's impossible to build a stable product if the core solution is not left intact.

@C0D4 This is why I like to be involved in the design process. Or better said process design. We (wel at least I'm not) aren't code monkeys.
At least I will give push back to the business analyst until I understand the process is indeed what it needs to be or work out a same proposal with him.

Recently other team members where building some convoluted sync actions into a change process I created. I challenged the BA because I could not see why this sync stuff what to happen only on pending changes (a very short timeframe). Turns out it could be completely decoupled, actually working better with the in place change process and also making it way simpler for the sync target that didn't have to be aware of the change process.
This was about a day of discussions (in total with all the stakeholders). Saved at least a week work on both ends and a lot of head aches in the future.