I'm trying something different on a personal project. Usually, I approach a project by first laying a bit of groundwork, and then by driving a series of "stakes", each of which goes bottom-to-top to implement a small number of related features. (I used to call these "spikes", but eXtreme Programming uses the term to mean something different.) A few stakes provide both a proof-of-concept and a sketch to base further work on. And they reduce the risk of building up a large infrastructure, only to find that you really didn't understand what the client wanted after all.
On this project, I'm working from the UI down, first mocking up screens with HTML::Template and dummy data, then working backwards from the dummy data, building what I need to get to real data. I've avoided working this way in the past after seeing the kind of organizational chaos that happens when higher-ups see what appears to be a polished UI, then completely fail to understand how much hard work remains to make it real. "The demo looks good, ship it!" is a classic antipattern. But this is a personal project. At most, I risk disappointing a few colleagues who see the mocked up UI, like it, and want it Real Soon. The upside is that I get usability feedback early.
The other thing I'm noticing is that working top down makes writing unit tests harder. When driving a bottom-to-top stake, I write unit tests on the way up, each tests building on the ones below. This feels a lot more solid to me than working top-down. Perhaps it's just a matter of getting used to working in this direction.
