4 ms·
Some lessons in software engineering take a long, long time to sink in. (For me, at least): - Don't generalize too early, which seems to address the original q
by geophile 14y ago
Some lessons in software engineering take a long, long time to sink in. (For me, at least):
- Don't generalize too early, which seems to address the original question pretty directly.
- Don't optimize too early.
- Maintainable > Correct > Fast. Maintainable = comprehensible. If it isn't maintainable, you won't know if it's correct. If it isn't correct, there's no point in making it fast.
- Minimize state. Deriving something from scratch every time it's needed leads to far fewer bugs, and the bugs there are probably far more obvious. Cache only when you need to for performance.
- Simplify as much as you can. This is the hardest one, because it can take a very long time to figure out all the ways in which a design that you thought was simple, turns out not to be.
- Simplify some more: The usual statement of the "simplify" rule is "as simple as possible, but no simpler". I don't think that's right. If you see a nice simplification at odds with requirements, push back on requirements.
- mbenjaminsmith 14y agoI'm starting to see this more clearly as time passes. I've spent years developing the ability to "engineer" things and only now am I realizing that I've learned to "over-engineer" things. Writing software has taken on a life of its own that is actually counter to its purpose. I don't think in terms of simplification though, I see it as "write what you need, when you need it." But I absolutely agree that you should avoid generalization aggressively and optimization should rarely be on the table. I also agree about minimizing state. Do it all "on the fly" unless there's known performance hit.
- sklivvz1971 14y agoThe phrase you may be looking for: do all that stuff at the "last responsible moment".