In one of my roles, the focus was solely on velocity. That meant no technical releases and an incessant rush to get the features out while still blaming people for issues. All that did was to instill a fear of breaking things and encouraged blind copy/paste and doing the bare minimum. One repo had scores of scripts that were several hundreds of LOC each while the difference between them was maybe 10-100 lines. People copied with misalignment/typos intact. When I attempted to refactor some stuff out to a library, the tech lead gave me a scolding citing the discomfort to Support team due to "lack of familiarity" (even though there wasn't any objection from Support team themselves) i.e. better propagation of the familiar ball of mud rather than the unfamiliar cleanliness (the unfamiliarity is usually only temporarily, until people catch up, and eventually results in eminently more readable code and actually speeds up dev velocity). This was just one example of out of a much larger ecosystem that had all sorts of issues built up over many years due to complete disinterest in refactoring.
One of the senior managers told us to focus on speed and that it was ok to break some things and we could fix it iteratively while ignoring and/or being unaware of the ground reality that doing so requires:
- avoiding blame game (not the case in this example)
- having sufficient manpower (again not the case in this example)
- having a culture of fearless refactoring based on technical judgement (definitely not the case in this example).
Apparently it is easy to think you can copy Facebook's move-fast-and-break-things and reap the benefits without fulfilling any of the prerequisites.
Even today, the technically undisciplined management still keeps chasing velocity and keeps being more frustrated that deliveries are progressively getting slower.
Allowing your engineers the freedom to truly own and maintain the code they're responsible for will necessarily result in refactors that sometimes even include rewrites and data migrations. On the surface and in the short term this seems risky. In the medium-to-longer term I think it results in happier employees, more confidence in the solutions and faster longer-term velocity.
I firmly believe you should design for the problem you've got now, and not worry too much about the future. You're usually wrong about it anyway! This is fine, as long as you do refactor when more requirements come along.
In order to do that you need a few things though: people who notice and care "oh we do the same in 5 places now, I should probably pull that out to a new module", a development culture that encourages and accepts that thinking, and a QA/delivery approach that doesn't say "oooh, that's a bit risky, do you have to refactor that?".