4 ms·
Go down the simple path to start, and refactor to a more complex solution when it makes sense to do so. If experience tells you the client is definitely going t
by blowski 2y ago
Go down the simple path to start, and refactor to a more complex solution when it makes sense to do so. If experience tells you the client is definitely going to ask for it later, add a “break condition” that tells you when you need to upgrade. You can put entry points into the code - comments, interfaces - to make it easier to do the upgrade.
- stef25 2y agoNormalise the DB from the get go (doesn't really require much effort), then charge for the fact that "actually we have a customer who has 2 email addresses".
- izacus 2y agoIn many many cases this doesn't work and it crashes and burns the whole project/startup company when its necessary. Sometimes messing up your fundamental architecture means that you hit a refactoring your company won't survive (while your competition grabs all the customers who wanted that feature your architecture doesn't allow). This is where experienced lead engineers earn their worth - they understand which parts cannot be fudged and fixed later and need to be there from the get go.