Say for example you're getting a web app project that interacts with a database.
How do you start your development? Do you start by designing your database, drawing simple ERD and writting a create scripts? Do you start by designing the look of your of web app, maybe using photoshop, then create a master page for it? or do you start by designing your domain models, with minimal looks, and apply a preetier design later on?
Please share you thoughts on this... Cheers...
I tend to do the last of those ideas, "start by designing your domain models, with minimal looks, and apply a preetier design later on" I like to make my application, of any kind, does what I want it to do before I spend time on making it look pretty.
Figure out how the users need to interact with your site first. What are they needing to achieve?
Let this define you ERD and the database model will quickly follow.
Then, when you actually start coding you'll be heading in the right direction.
Many will also say, write your Unit Tests first. It's hard to do but often worth it.
You start by deciding which way you start. No but really, it depends on too much factors to have a general answer. Do you develop using concepts of agile development, are there specified functional designs, did the client give you strict requirements, what is your own experience etc..
Generally we start by developing our business objects first, then creating views for them using sample data / fake databases or sometimes even plain text files. From there, we start filling in the bits and pieces. If not all requirements are set, it's best to keep the database outside your development as long as possible. That way you prevent yourself from having to change your db, sprocs and interaction with your db everytime.
UI and DB, but it depends which one is really first. The UI is a very important thing because your customer has to work with it in the end (some say there might be developers who sometimes forget...). The database design is a very good way to put (some) structure in all the business needs which aren't always specified in a strictly and well structured way.
This is junior's experience, I've been working in development since 2004, beginning with a 4-year-apprenticeship in a development company.
Cheers, Matthias
I start with the functional UI, moving from there to the business layer and db (usually in tandem to start with). Design is normally provided in some respect by the client, so I try to apply that early on, without letting it get in the way. I like to get the domain sorted out in one step (minor changes are acceptable later), and I create my scripts as I get to them in my code.
It sounds like a bit of a runaround, but it works for me.
I definitely start with a UI Prototype. Clients never know what they really want untill they see it.
A simple change on a UI can translate to a dramatic change in the core components of your system. So rather let the user play with a pretty prototype until they are confident it's what they looking for, and then dive into system objects and database design.
With regards to Database and System objects, I find it difficult to decide which way to go. Going database first definitely influences my class design, so I try go object first as much as possible. It turns into a more human design IMO
Depends on the Project Id' say. Usually it's good to have a Photoshop mockup to show your client what they're getting.
On small no-maintenance projects I try to start by modeling the database first to get a better overview on the structure. Then it's usually quite easy to create a Web Application around it.
On bigger projects I usually start by creating (basic) prototypes of critical pieces of the software. I then show those to clients and afterwards throw them away. They're just there to help me understand the upcoming challenges better.
But as said, it's a matter of taste and project.