[kaylarose]

This is how I approach project design as well (after the POC phase): Top down (API first). Then (not covered in parent article) bottom-up, (a.k.a. what building blocks does that API need?). _Everything else is just glue._

If you exclusively do one or the other, you end up in bad territory. Top-Down: Results in excessively bloated API logic. Bottom-Up: You end up with a muddy API, that is overly complicated & hard to use (it's more of a RPC lib than an API).

[phamilton]

In an MVC setting (be it webapp or normal app) I find that I frequently write my Controller Last.

I design the View (top down), then I design the Model (bottom up) and connect them up with the Controller.

[alttab]

This comment is under rated. Think about the intteraction (view), write tests and document the model, then fill it out. Correct tests, fixtures/factories and model as necessary.

The controller should be thin, make 1 or 2 calls to the model while mapping or cleaning input, then the response. If your controller actions are thick then your model sucks and isn't encapsulated or you have complicated response logic. Avoid these by writing great encapsulated models. understand the presenter pattern.

I've worked in sections of code that doesn't consider my opinion as advice and dechipering wtf was going on was anything but quick, and I probably introduced bugs because I couldn't understand how everything worked.

Tldr, controllers are glue code. Applications made entirely of glue doesn't even sound right saying it.