Security. Adding security as an afterthought normally leads to insecure systems. Always analyze your security requirements, perhaps you decide that some parts do not need strong security, but at least you have done the analysis.
> Applications of Zero One Many. If the requirements go from saying “we need to be able to store an address for each user”, to “we need to be able to store two addresses for each user”, 9 times out of 10 you should go straight to “we can store many addresses for each user”, with a soft limit of two for the user interface only, because there is a very high chance you will need more than two. You will almost certainly win significantly by making that assumption, and even if you lose it won’t be by much.<p>I agree in general, but for the address example in particular I can't remember how many times I have to provide a shipping address and a billing address, or residential address and mailing address, etc. I also can't remember any time interacting with a system that asks for 3 or more addresses.
YAGNI only applies for a "top-level" applications. For libraries used by third parties (e.g. the standard library of a language) you want clients do be able to do things you haven't imagined, so different trade-off are in place. For software which cant easily be updated, like mars rover software, you also have to prepare for all eventualities up front.<p>I don't agree with the article that you should <i>always</i> select a relational database up front. Should Calculator really use a relational database to persist configurations? This is exactly where YAGNI applies.
Timestamps needs to come with a huge warning. If you want to have a created_at timestamp for every record, go for it. HOWEVER be very, very careful about how you use this field. The semantics of created_at are the time at which the record entered the database, that it is, nothing more, nothing less. Trying to use created_at to represent something that happened in the real world bites so many developers. Users will want to tweak the value of the field since there was a delay between the event occuring and the event getting input into the system. Also once you start supporting data imports, backups, and restores, its clear that created_at has nothing to do with when the event was actually created.<p>Honestly I still lean away from automated timestamps just because the knowledge of when a record entered the database is not that useful and the danger of some developer using the field incorrectly is too high.<p>created_at/update_at are nowhere near a proper logging solution and just give developers the illusion that they have one.