The worst code I've ever written is because of shifting or unforeseen requirements. It doesn't matter how good the architect is if the foundation is built on sand.
100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clear requirements is what leads to bad code. I am fine with helping gather the requirements but if I get a list of unclear and shifting requirements and just is expected to fix it I obviously will fail.
I've worked on projects where if you wait for the requirements to be firmed up, you'll never be able to do anything. Depends on what you're trying to build if that means you need to stop and figure out the requirements or if you need to just deal with the shifting sands. Aircraft built for moving requirements don't work so well; but lots of things are fine with moving requirements. It'd sure be nice to know how users are going to use your product before you build it, but sometimes you build what you think is wanted, and people only use part of it or use it for different things than what was intended, and it's better to adjust and refocus than to start a whole new development process with the found requirements.
Of course you should not wait around. I think rather the opposite that the engineers should be more involved in working on the requirements. The issue is more rushing and being expected to magically just conjure something. Changing requirements is a fact you just have to live with in many industries.
Changing requirements is fine. Changing requirements when it was eminently avoidable is very, very bad.
If I asked you 6 months ago if you might ever consider something other than credit card payments, urged you to seriously consider this and you say no, you shouldn’t come to me now and say that bank transfers (bank transfers!) are absolutely indispensible.
It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
> This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
Being delivered faster or cheaper isn’t the goal. The goal is to look good while doing it. Telling your bosses ‘Yes sir!’ Is apparently a lot more palatable than saying ‘No can do’.
