> When you know the requirements, model the data first. Data comes first because data lasts longer than code. Flexible data lets you do more with less code. And

> When you know the requirements, model the data first. Data comes first because data lasts longer than code. Flexible data lets you do more with less code. And if the data is very well defined you can usually use fewer language features, too - which is a bonus to maintenance later. Think of features in data terms first and lifecycles later. Boy am I SO GLAD to see someone say that! I think of my approach as "Data-Driven Development", rooted in my days of scientific programming. The data is what matters. On my largest project to date (8 months, entire business system) I spent 25% of the time just on the data store schema. Needless to say it worked & evolved without issue over 5 years. Yet (at least in the PHP community) the fad is currently Domain-Driven Development, BDD, and architectures ("another travesty of reflection and classes-on-top-of-classes"). > The maintainers will feel like geniuses because they'll keep finding clever ways to use the existing data better Oh yes, that's how my oldest systems are. Spaghetti code in parts, but the data keeps on giving. Thank you for taking the time to write this, you've ignited a small flame of enthusiasm in me and reminded me why I enjoyed doing what I do!