Which first? Database, Interface, or Other.

[roopurt18]

When starting on a brand new project, do you like to create the interface or database first?  Or is there something else you start designing?

 

Assume you aren't using any code generation tools as they may skew your decision.  For example some tools will build a generic interface when pointed at a database; in this case you would obviously create the database first so you can use the interface generation tool.  So again, assume you would be coding everything by hand.

 

Experience has taught me it's usually better to start with the interface.  My reasoning is the interface deals directly with what the client or user needs.  These needs change constantly and especially while a project is young.  Therefore the interface will undergo many iterations before being approved.  Since the database is merely persistent storage of what's in the interface, it makes the most sense to me to design it after the interface has become mostly static in design and then connect the two together.  Or in other words, the interface usually dictates the database design.

 

I'm curious how others feel.

[Daniel0]

Insofar it's possible, I delegate the task of frontend design to someone who is better at making things pretty than I am. For that reason it makes sense for me to start with the database design based on the project's requirements. I would probably start with the database even if I would be the one designing the frontend as well. I'm more of a programmer than designer, so for me the essential part of the application is the database, and the application revolves around that and the contents within it.

 

Exactly how the user interfaces with the data shouldn't have any impact on how it is stored. As I see it, you can completely revamp the UI without touching the database, but you cannot completely revamp the database without touching the UI because the UI is a visual representation of the database, so I think it's more important to have the database sorted out first.

[jackpf]

I just write some code, make a database, don't really care what it looks like

 

So yeah, I voted "other". I guess I'd define what I code first as..the code.

[jcombs_31]

I think any data driven website should start with the database.  The only time I whip out pen and paper is when designing a database, and this is where I'll start with a big project.  I like to draw up a quick and dirty ER diagram and go from there. Once the database is established I'll go back and forth from design to function without any real definitive direction. 

[Ken2k7]

Well, before I start, I would brainstorm key classes, DB structure, security etc. and have them all on paper or on my white board. There may be changes to the DB structure as I go along, but nothing that would take away from how my classes would work. Just a change in SQL.

 

Interface generally comes last. I generally start with writing a few key classes or setting up a MVC structure. Next comes some HTML work on getting a layout to display correctly cross-browser for Firefox 3 and IE 7. DB kind of come in much later because I generally don't need to run SQLs right away. DB tables are not something I start creating at first because it tends to get changed as I think of better solutions or added functionality as I start writing the project. And I hate running a SQL just to change the DB structure. So it usually comes last so I don't have to bother with it as much. If I rush into DB, I know I'll miss something. Interface is like last.

[samzor]

Depends  if i know how to write the application, if its something which i have no idea then:

 

Use Case diagrams to discover the variables to pass through $_GET and $_POST, expand the Use Case scenarios and then build a prototype schema, from this you can usually create an Adapter Pattern and which would form part of the Model component of a MVC for instance.

 

Essentially once you get use case and the db schema done then a class diagram can be built. All these quantities are expanded as new facets of the application are discovered. Interesting point i make is unless i know a lot about how my solution will work then i don't try and write a complete interface class first as i usually make too many mistakes.

 

Often write code scenarios of use to justify the addition of a method to an interface first.

 

[dbo]

While I do agree that the data can and should live independent of the design, I typically find it best to "feel" the interface before starting to write code, especially when working with a client. The reason being: if client randomly says I'd like to have "this" over here.... that's fine. I don't care where it's positioned so much, but if I haven't accounted for the "this" in my database design it's going to be awfully hard to put it anywhere.

 

Client's don't typically understand or care about database design, but they certainly care about how the thing looks and feels. If  you work through the interfaces first it's going to more appropriately manage their expectations and it's going to give you the data you need to build the application.

 

Here's a short online book sorta about the topic from 37signals.com: http://gettingreal.37signals.com/toc.php

It's a very easy read and I highly recommend it.