4 ms·
No matter what you build someone will come along later and try to rewrite. If it is built too well with too many future cases in mind it will be too complex.
by ipaddr 2y ago
No matter what you build someone will come along later and try to rewrite. If it is built too well with too many future cases in mind it will be too complex. If you write something simple and basic someone will try to add their complexity. If you write in one language someone will try to use something different. Same goes for framework.
Write for your current requirements not some future state because people will say your work was subpar or overkill regardless because you are not around to defend your decisions and putting you down raises them up.
Things you learn after 25 years.
- Closi 2y agoThen let someone come along and try to rewrite and improve - but if your solution is so flimsy it forces a rewrite, it's just poorly made to start with.
- boznz 2y agoOr old. Not many technical decisions stand 15+ years in any organisation
- d_sem 2y agoSome data retention requirements are mandated by law and it is necessary to develop robust systems that can stand the test of time. I've seen 15 and 25 year retention periods for data in safety related applications. Things my interns learned in the first month as part of new hire training. My quip above is to illustrate that in a dynamic and complex field its important we don't over index on experience.
- dataflow 2y ago> No matter what you build someone will come along later and try to rewrite. > If you write something simple and basic someone will try to add their complexity. Note that extending != rewriting.
- jvans 2y agoThey mean rewriting. People love rewriting stuff they didn't write
- jvans 2y agoThe desire to rewrite something is the single biggest red flag for me that someone has questionable technical decision making skills. Yes there can be good reasons for it, but my priors shift dramatically once I hear someone suggest it
- kdazzle 2y agoI used to agree, but there’s so much software that is just so bad. Wrong DB, bad framework, crazy abstractions, black box magic, no security, behavior that is just wrong, etc. The dev team going away for 3 months to rewrite is probably a bad idea, though. There are definitely good ways to rewrite and then not good ways.
- gregors 2y agoI'll agree with you if you mean - entirely en masse. I specialize in fixing legacy software systems that have ground to a halt development-wise. Blanket rewrites are almost never a good thing, but partial rewrites are a wonderful tool. Like most things in this industry there unfortunately isn't a hard and fast rule. Everything is extremely context-dependent.