I firmly believe that the goals is aligned on both sides. Client wants a feature "just works" by a certain date, and programmer wants to ship that very feature (without breaking anything else) on that certain date.
The impedance mismatch is that programmers see (code) quality as enabling higher velocity (work on new features without needing to maintain old ones) with the trade-off being the upfront cost. The client sees that the time it takes to deliver feature X as being proportional to delivering feature Y and Z.
The catch is that it is very hard to communicate that delivering feature Y and Z would be quicker (or not needed) if feature X was designed properly. This is because you can only approach this in hindsight (orthogonal thought: this is why upfront waterfall fell out compared to iterative agile).
The hard truth both sides don't want to admit is that the programmer does not know what they are building and the client does not know what they are asking.
Instead of the client wishing that the programmer had more domain experience and the programmer wishing the client had more technical experience, there should just be a stronger focus on empathy and letting things fail as part of the process.
I find it interesting that when things fail, client knows exactly what failed and programmer knows exactly why it failed. Must have something to do with hindsight :)