How I learned to do things backward
My typical approach to everything is to figure things out at a high level, then dive into various parts to fill in the details. That's usually how I do software design and implementation, it's how I figure out how to make food, it's just a basic philosophy for me. I do it naturally whenever I have to do anything.
Or rather that's what I've been telling myself for the last couple of years. Some of my recent experiences have shown me that no, this is not how I approach problems in general. This is definitely for the best, since if I always used the same approach I would start to think of it as a silver bullet, and that's a trap I'd like to avoid.
Lately I've been running an RPG game with some of my friends, and I've been planning another RPG setting that I'll be starting up soon. (RPGs are a great way to kill your friends outside of video games, by the way.) When I first started out, I tried to figure out a plot at a high level and tried to fit characters and settings into that theme. When I ran a few sessions doing things that way I quickly realized that the players were overpowering my characters and were finding holes in my plot.
At that point I didn't learn my lesson and I just tried to re-apply a high-level design but decided to just iterate to flesh out more details. What happened then is my players would just ignore what I came up with and come up with things that I couldn't anticipate. It's like they're a bunch of fickle users or something.
Eventually I settled into a pattern and didn't even realize that I had found the perfect solution to the problem: I came up with the details and then built everything else around it. I arrived at a bottom-up design strategy from my usual top-down strategy because it fit the situation better.
See, I wanted to give my players interesting characters to interact with and interesting places to interact with them in. When I came up with a high-level idea of how things should be, I ended up restricting my own creativity with this self-imposed constraints of theme and story. If I ignored those and focused on creating characters and settings that will be really fun to work with I ended up making much better choices for my players. At that point it was a lot easier to fit those ideas into an overall plot than it would have been to use such a plot to drive the character designs.
It also helps with the improvisational nature of RPGs if I have a bunch of loose but detailed ideas that I can insert anywhere into the story. If I expected my players to turn left but instead they turned right, I can just pick up a floating idea and put it in their path. It looks like I had everything planned out in advance when really I just had the details ready in case I needed to fit them in somewhere.
I've been building my next RPG setting completely contrary to my nature. I came up with a few organizations that would populate my setting, then I gave those organizations personalities and notable individuals, then I figured out their relationships with each other and their long-term goals, then I determined a theme that allowed these organizations to reasonably coexist. At that point I came up with the overall plot of the game. And as a very last step I looked at different RPG systems that can support this setting (which is usually the first thing people start with when making new games). Because I wasn't constrained by a theme in creating my setting I feel I did a much better job using my creativity effectively.
"But this is a software blog," you're thinking, "What does this have to do with anything? Did I leave the ice cream out of the freezer again?" Well, my friend, the points I've made here apply to software development as well, and for the same reasons.
Consider prototyping, which is coming up with crazy ideas and implementing them to see if they work in practise instead of just in your head. Usually when prototyping is done it's to prove one core idea is feasible. Everything other than that core idea is unnecessary. A prototype is therefore best designed from the bottom up rather than the top down. You need to start with that core idea, then keep building it up until it becomes something good.
I've been doing a lot of prototyping at my new workplace here in Toronto which has really been the spur of this post. In order to try out new ideas effectively you need to shed the constraints of frameworks and other such high-level constructs and dive into the details without any ideas of what the final product will look like. It frees you to make the best decisions for the core idea without compromise.
Of course bottom-up design is also not a silver bullet. It's just one more tool that shouldn't be ignored. If, like me, you naturally build things from a high level and work your way down, you might find that some things aren't as easy as you think they ought to be. Maybe a change in perspective will help find a new solution — you might be constrained from above.