Personally I don't get the argument that you can either have speed or well architected systems.
Yes, if you build features outside the scope of the system to meet unforeseen features it's just scope creep and a waste of time but if you take a few minutes to actually think before you code the actual implementation time is usually on par (assuming you're not working in system that has allowed bad programming practices to take place; isn't DRY, etc.).
I've worked with people that copy and pasted half of their code base on a few occasions. Whenever a change needed to be made to a few of the more complicated systems you had to give it to the original 'rockstar' developer because he was the only one who knew every location it was used in the system.
To me it's just a sign of laziness. The effort to introduce design patterns and keep your code DRY is trivial. Just keep scope in mind and don't build systems to anticipate unforeseen features.
I do get the whole MVP we need to get it out the door argument but usually if you hire people who know what they're doing and aren't just an inflated ego (we all know those sorts of developers) it's really not a problem because they'll take the few minutes to think before they implement.
Yes, if you build features outside the scope of the system to meet unforeseen features it's just scope creep and a waste of time but if you take a few minutes to actually think before you code the actual implementation time is usually on par (assuming you're not working in system that has allowed bad programming practices to take place; isn't DRY, etc.).
I've worked with people that copy and pasted half of their code base on a few occasions. Whenever a change needed to be made to a few of the more complicated systems you had to give it to the original 'rockstar' developer because he was the only one who knew every location it was used in the system.
To me it's just a sign of laziness. The effort to introduce design patterns and keep your code DRY is trivial. Just keep scope in mind and don't build systems to anticipate unforeseen features.
I do get the whole MVP we need to get it out the door argument but usually if you hire people who know what they're doing and aren't just an inflated ego (we all know those sorts of developers) it's really not a problem because they'll take the few minutes to think before they implement.