I have been coding for a good bit, and I found a project I want to work on -- a python web app using django + mongodb.

I know what I want my web app to do. When you are in this circumstance (just starting a brand new project) where do you start? What do you code first? Do you code the views first?

Hope this hasn't been asked before (I did a quick look), but I could use some general direction.


It is best to start with your model. Your controllers will be based on your model, and then you make the views to access the controllers.

UI/View logic should always be the last thing you work on, as it can change as the data changes, but if you design your model first, you are working using a bottom-up approach, so by the time you reach your view, you'll have everything established and know how your views are supposed to access the data.

Ideally, you'll be doing test cases on each step, so that when you reach your view, you know exactly how your going to be persisting and retrieving your data.

  • +1 - If there's something in the UI that helps with designing an app, then just do some crude sketches, but there's no need to code it first. – JeffO Apr 11 '14 at 20:40
  • 1
    +1 - Everything follows from the model. In fact the model is so important there are multiple UML diagrams describing models in various ways; yet there are no view diagrams that I know of; and the controller diagrams all reference the model in some way (e.g. showing data flowing through the system, or as arguments in a class diagram). – user22815 Apr 12 '14 at 20:16

The practice of "outside-in" test-driven development recommends coding the UI first, driven by tests in which you stub out the back end. You continue working down the layers of your application like this, testing (and coding) each layer of the onion until you are ready to move inwards; the model is typically the last thing you write.

This has advantages and disadvantages. Having a working UI prototype you can show customers means you can iterate the design of your UI quickly without getting bogged down in the data model. It also helps you keep your UI decoupled from the model, and it feels encouraging to have a visible working UI early on in the development process.

On the other hand, the UI is typically much harder to test than the model. It requires discipline to remember to test your model code at a lower level, and not rely on fragile acceptance tests for all your testing.

I'd recommend a balanced approach, switching between outside-in and inside-out styles as is appropriate for the situation at hand.

Not the answer you're looking for? Browse other questions tagged or ask your own question.