3 ms·

> I think that one of the fundamental principles of software engineering is to code in such a way that future change is contained Uff...that's a heavy statemen

> I think that one of the fundamental principles of software engineering is to code in such a way that future change is contained Uff...that's a heavy statement. There is no such hard and fast rule. In fact its mostly the opposite, I argue. 90% of the abstractions don't ever get used. Write twice and then make an abstraction. I think you're doing software engineering the wrong way, sorry to say.

amw-zero 6y ago
Last I checked, all businesses continuously modify their codebase. So planning for change seems to be the only way to survive in such an environment. Not sure what your experience is where you’d label this as “wrong.”
- dsego 6y ago
  When the boss decides they want email forms instead of the beautiful react form you built, because the customer success team thinks clicking links is adding friction, how much of that well planned react code will be reusable?
Cpoll 6y ago
It's a shame that you're getting downvoted, because I see what you're getting at, but I don't think you're talking about the same things. I think you mean YAGNI, and I agree. I've seen plenty of over-engineered solutions. On the other hand, when the parent say "future change is contained," I take that to mean separation of concerns, plugin-based architectures, decoupling of business logic, etc. And I can also say I've seen plenty of under-engineered solutions, where you need to change constants in five places, and twenty different if-blocks just to add a simple feature. An experienced developer who's been using the codebase a long time can sometimes spot when an abstraction is needed right away. Conversely, an inexperienced developer won't write twice and make an abstraction, they'll write five times and make a headache for everyone.
kybernetikos 6y ago
> 90% of the abstractions don't ever get used. Write twice and then make an abstraction. Coding to avoid or contain change does not mean overabstracting. Overabstracting generally means more change down the line, which is one of the major reasons its bad.

amw-zero 6y ago

Last I checked, all businesses continuously modify their codebase. So planning for change seems to be the only way to survive in such an environment. Not sure what your experience is where you’d label this as “wrong.”

dsego 6y ago
When the boss decides they want email forms instead of the beautiful react form you built, because the customer success team thinks clicking links is adding friction, how much of that well planned react code will be reusable?

Cpoll 6y ago

It's a shame that you're getting downvoted, because I see what you're getting at, but I don't think you're talking about the same things. I think you mean YAGNI, and I agree. I've seen plenty of over-engineered solutions. On the other hand, when the parent say "future change is contained," I take that to mean separation of concerns, plugin-based architectures, decoupling of business logic, etc. And I can also say I've seen plenty of under-engineered solutions, where you need to change constants in five places, and twenty different if-blocks just to add a simple feature. An experienced developer who's been using the codebase a long time can sometimes spot when an abstraction is needed right away. Conversely, an inexperienced developer won't write twice and make an abstraction, they'll write five times and make a headache for everyone.

kybernetikos 6y ago

> 90% of the abstractions don't ever get used. Write twice and then make an abstraction. Coding to avoid or contain change does not mean overabstracting. Overabstracting generally means more change down the line, which is one of the major reasons its bad.