I'd say because most of the time,
1) the product is designed iteratively, and not API-first (where a clean spec of the API could be done) but most-obvious/target-usage-first (where hand-made/refined queries are done);
2) and then you patch things on top of it.
You may claim that there's a lack of architecture/thinking into this. There is. Precisely because when you build something new, or something you don't master, you go for it iteratively, instead of deep-thinking it.
And after that, when you have your v1, you can redesign it "properly" with a contract, etc. as a v2.
And here again with the v2, you will be asked to build/integrate some other new stuff. Or usage will evolve in a way you didn't project. So you will end up patching either your API directly, or the contract first.
And reactively, again.
And no, architects won't be involved, because their time is supposed to be best spent doing pre-sales, or proof-of-concepts, or suggestions for v(n+1), rather than mingling with developers or production teams about operational matters. /sad sarcasm
You may claim that there's a lack of architecture/thinking into this. There is. Precisely because when you build something new, or something you don't master, you go for it iteratively, instead of deep-thinking it.
And after that, when you have your v1, you can redesign it "properly" with a contract, etc. as a v2.
And here again with the v2, you will be asked to build/integrate some other new stuff. Or usage will evolve in a way you didn't project. So you will end up patching either your API directly, or the contract first.
And reactively, again.
And no, architects won't be involved, because their time is supposed to be best spent doing pre-sales, or proof-of-concepts, or suggestions for v(n+1), rather than mingling with developers or production teams about operational matters. /sad sarcasm