Well, no doubt I'm an oddball, but for desktop apps (not web) here's what I do. I consider almost any app as just a glorified editor. That is, it has a data structure that needs to be persistent, and a UI to let the user put information into that data structure and get it out.
For the data structure, keep it simple, simple, simple. I consider it just a repository for information, with as little redundancy as possible. I do not want to build data structure that exists for the purpose of being a visible manifestation of the underlying data, such as tree controls, etc. because then that needs to be kept in agreement with the underlying data, and you get into all the issues of how to keep redundant data consistent. (Example: for graphics, don't build it, draw it.) If I cannot avoid creating redundant data structure, I stay away as much as possible from notification-style programming that tries to keep redundant data structure in tight agreement. Much of the buglist and performance issues arise from that. Rather I prefer loose coupling, where a certain amount of inconsistency can be tolerated and is managed by processes that run once in a while to propogate changes.
For the UI, I was a big believer in OOP and MVC-style UI coding, until I discovered this in 1986. Now I'm spoiled, and I can get complex UIs coded in a fraction of the time possible by the usual control-event-handling style, and they are trivial to modify as requirements change. But so far, I'm in the company of maybe only 3 people in the world who use it, because it is definitely not mainstream.