11–20 of 49 posts
How about some actual examples? This seems like a fluff piece article written in 10 minutes without much real content.
Scope context matters in hitting the Goldilocks spot in the engineering. But given the choice of over- vs. under-engineering, overshooting a modest amount absorbs the inevitable scope creep more readily.
I have had this fight with Agile absolutists. They claim you should only think about the next sprint and not design any further.
It depends on use case. If what you are building will be public, then: "over-engineer the concept, under-engineer the implementation". When you over engineer the concept, you start thinking about what might come next, you start seeing different applications on top of your solution. But deliver only what's needed now. if what you are building is fully internal: "under-engineer, move as fast as you can so you have an i…
Exactly. Design in a way that it's possible to add future requirements.
I always live my life by: You can always make something more complicated, but once its complicated (and more likely deeply re-used and embedded in your system), you are going to have a hard time making it simple again.
One challenge with the term over-engineering is that it implies that the over-engineered solution would be generally superior to the under-engineered one were it not for the extra cost. The article rightly points out that this is not true, but it's something that really isn't discussed as much as it should be. A good example of this would be avg's teardown of the Juicero, in which IIRC he described it as under-engine…
While not the intended audience, Systemantics is one of the most educating books on software architecture in existence.
Newbie devs think under-engineering is a problem. Experienced devs know over-engineering is a problem.
It doesn't seem like Glassonos is describing over engineering as I understand it. Possibly he's describing scope creep? In general, people should actively discourage extra scope from creeping in to their projects. But I need some examples to illustrate what I'm talking about, as does the OP.
I really disagree with the pros listed on over-engineering, specifically "future-proofing" and "reusability". I doubt you can accurately predict the future and whatever assumptions you make will likely be wrong in some way. Then you are stuck having to solve the problem that you created by trying to predict. As for reusabilty, it's similar. Start with solving what you have to, then abstract as you see it fit. Again,…
When I think "Under engineer", I think "keep it simple, because you can't predict the future". Simplicity is a great enabler of flexibility and tends to go hand in hand with scalability.
Newbie devs think under-engineering is a problem. Experienced devs know over-engineering is a problem.
A half-baked thought: It's interesting though isn't it, that the "immature" approach is to try to be extra vigilant. You'd think an immature coder would just want to hammer things out quickly. I wonder if it's because they learned that lesson at some point (maybe in college) and are overcompensating, trying to be extra mature or something.
(Shout out to Don Martini, who helped me more than he knew in my first job, as I was trying to grow into a professional programmer. Ditto Steve Hanka, who helped me in the same way on my second job. If either of you see this, thanks!)