I'm been in tactical mode lately, building an advertising management system for one of our projects. Actually it's v2, the first one is working and doing what needs to be done (definitely minimalist), but as we started looking at wrapping up the major development we decided to add a few things that had been on the wish list - but with the caveat that the time and resources to make the change were time boxed.

I tend to look at all development work from a data perspective. A lot of that comes from being a DBA of course, but also from being a business owner. I want to be able to answer the questions that matter to me, and in some cases I may not be asking the questions a developer would expect. That DBA experience also leads me toward normalized designs and in truth designs that often more complex than needed. Of course the hard part is knowing that you've exceeded the complexity threshold. The opposite end of the spectrum is the agile design approach which embraces YAGNI (you ain't gonna need it) and focuses on building for today.

Time boxing (or cost boxing) is an easy way to answer the question about too complex, though it separates the zealots from the pragmatics pretty quickly. Once you know the resource constraints, you then build a solution that you know you can get done. Survivorman is an example of this - I remember an episode where he had the choice of building a fire to feel safe, or building a platform so he could sleep off the ground and avoid most of the insects and worse. He could not get both done, he had to pick.

Back to the minimalist design. I had 2 weeks to redesign and fully implement the tables, workflow, invoice generation, and to connect to to a site was already up and running, with the final UI construction to support the design set aside as a later task. Two weeks is not long! As we worked on the design we had to make some hard choices, and the trick - to call it something - is to have a good feel for what is important and what's not, and the harder trick is to know what you can scrimp on now and change later without it causing major reconstruction.

As DBA's we should be masters of abstraction and refactoring. Between synonyms, views, computed columns, and triggers we have ways to put things in one place and make them appear differently or in a different place as needed. Only with a good understanding of the options and the final (someday) goal can you do good minimalist design, and there is definitely a subtle difference between good and not good.

You aren't always going to need it. Think about spending effort on the things that matter and setting yourself up to make changes later that will be easy refactorings.