Well, you seem to be mashing together a couple of somewhat related things but not in a way that seems to connect logically.
You start with over engineering, which is about code design and implementation and then go about features (not sure if there's a word for it, perhaps over-productization?).
Overengineering, basically engineering things a certain way just for the sake of it, is a bit of weird case. It's weird because there will always be a moment when you're doing things to preempt problems. When you're just beginning a project, you make decisions that solve potential issues you know about from experience which you might hit (but then again, might not - experience is never 100% replicable). While it's natural to happen, people tend to forget that different people come with different experiences and different takes which they will try to apply all at once in that stage.
Point 2, which is more a rule-of-thumb kind of guideline, is to never engineer extensibility before it's needed. Don't design a contract that's currently used once. Design it when you have at least two uses in mind, which are needed right now.
On the second matter, features (which is what Ron Jeffries specifically refers to) are no longer a development decision. Nowadays we have (generally, unless you're a garage startup - though even then ...) product designers that describe features. It's still a great thing to not implement something unless it's needed (and particularly in startups people avoid it like fire when going for an MVP) but it's beyond the domain of pure development. Overengineering a product (in the sense of taking a convoluted approach to feature implementation for the sake of opening up future options) would probably get you skinned alive in a time-pressed startup (but unless you double it with hurried spaghetti code, it won't kill anyone except probably accountants). Overengineering an implementation (architecture, code) is a more immediate development issue that's guaranteed to come haunt you in many different ways.
Thanks for this comment, it really made me think. When I talk about overengineering a feature, I don’t talk about defining scope of it. For me, as a developer, overengineering a feature is adding unnecessary complexity to code only because of a fear of the future problems. It’s all about that thin line between building right amount of flexibility into a code and overengineering.
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.
Well, you seem to be mashing together a couple of somewhat related things but not in a way that seems to connect logically.
You start with over engineering, which is about code design and implementation and then go about features (not sure if there's a word for it, perhaps over-productization?).
Overengineering, basically engineering things a certain way just for the sake of it, is a bit of weird case. It's weird because there will always be a moment when you're doing things to preempt problems. When you're just beginning a project, you make decisions that solve potential issues you know about from experience which you might hit (but then again, might not - experience is never 100% replicable). While it's natural to happen, people tend to forget that different people come with different experiences and different takes which they will try to apply all at once in that stage.
Point 2, which is more a rule-of-thumb kind of guideline, is to never engineer extensibility before it's needed. Don't design a contract that's currently used once. Design it when you have at least two uses in mind, which are needed right now.
On the second matter, features (which is what Ron Jeffries specifically refers to) are no longer a development decision. Nowadays we have (generally, unless you're a garage startup - though even then ...) product designers that describe features. It's still a great thing to not implement something unless it's needed (and particularly in startups people avoid it like fire when going for an MVP) but it's beyond the domain of pure development. Overengineering a product (in the sense of taking a convoluted approach to feature implementation for the sake of opening up future options) would probably get you skinned alive in a time-pressed startup (but unless you double it with hurried spaghetti code, it won't kill anyone except probably accountants). Overengineering an implementation (architecture, code) is a more immediate development issue that's guaranteed to come haunt you in many different ways.
Thanks for this comment, it really made me think. When I talk about overengineering a feature, I don’t talk about defining scope of it. For me, as a developer, overengineering a feature is adding unnecessary complexity to code only because of a fear of the future problems. It’s all about that thin line between building right amount of flexibility into a code and overengineering.