2 ms·
To me, whether you use waterfall or agile or something in between, or whether your managers give you full independence or measure every little metric, or whethe
by thrashh 3y ago
To me, whether you use waterfall or agile or something in between, or whether your managers give you full independence or measure every little metric, or whether you choose to do a lot of design up front or build a MVP right away, ultimately has little impact on the future of your codebase.
Nothing replaces experience in the domain. For an example, if your domain requires N-addresses per customer and you build the system allowing only 1 address across all your systems, you will probably be stuck in a refactor/rewrite hell-hole down the line. I don't think any amount of planning or lack of planning or waterfall or agile could guarantee you figuring this out, but someone that has worked in the field for 10 years could tell you in 5 seconds.
- appplication 3y agoDefinitely agree, and I think the place that I’ve seen most errors manifest is often the data model (including your example). APIs can always have a v2, classes can be extended, front ends can be reworked… but the data model is essentially the last line where abstractions end. It will forever codify the burden of representing hopeful future states while needing to account for every past state. Database migrations can be costly, risky, and often difficult to revert. I might also see the world this way right now because I’m currently deep in data model/migration hell with my current project due to my formerly (and possibly still presently) incomplete understanding of how the system and use cases would evolve over time.