I feel like balancing upfront planning vs the cost of refactoring later because of overlooked needs is one of the harder things about software. Identifying those things that would be hard to bolt on later seems like an important consideration.
It definitely is, but it's a skill that constantly gets exercised as a developer. You get better at it with time, learn how to gain time by overscoping other areas and learn where you can cut time and budget from others.
IMO, the majority of software is learning to engineer people less than engineering code
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article, I enjoyed reading it!
I feel like balancing upfront planning vs the cost of refactoring later because of overlooked needs is one of the harder things about software. Identifying those things that would be hard to bolt on later seems like an important consideration.
It definitely is, but it's a skill that constantly gets exercised as a developer. You get better at it with time, learn how to gain time by overscoping other areas and learn where you can cut time and budget from others.
IMO, the majority of software is learning to engineer people less than engineering code