Which layer should we start with when building an application?

[John_165]

When we build an application, which layer should we start with?
From top (UI) to bottom(Data Layer) or bottom to top?

[rproffitt]

After decades of software development I start where I can. Agile seems to toss out the old ways of writing your software design specifications and more. You iterate and move to your goal without the docs. I have yet to see this when money is involved. They want docs, presentations before code.

[JamesCherrill]

I don't have time for a full reply now (I'll try later) but the short version is:

Start with the API definitions for the distinct layers. Eg if its just MVC then define the model's API.
In multi-layer systems I would still start ith the API for the layer below the UI because that effectively defines the system's visible functionality.
This gives you a clean architecture and allows development of the layers to proceed in parallel. It also maximises the chances that the client may understand exactly what he is signing up for.

ps: rproffit: I was Principal Consultant at Easel when Jeff Sutherland et al developed Scrum based on the informal processes we were using in the field, and I remain a fan to this day. Almost anything woud be better than the traditional guaranteed-to-fail waterfall method!

[Yrth]

People have been debating the top-down versus bottom-up versus outside-in versus inside-out for decades. The correct answer is "none of the above". The best place to start is wherever the rubber meets the road, so to speak. Wherever the question mark is. You're writing the software to address some problem of some kind. It doesn't matter what. For the solution to that problem to exist, what is the most important question that has to be answered? Start there. If that's an assembly-language layer right next to the metal, or a network abstraction that doesn't actually exist, or a database design, or a user interface, or a search algorithm, or a peculiar species of linked list - it's something. Until that question is answered, the rest of the system is meaningless, but once you've got that question answered, then the shape of the rest of the system will be much clearer. There may be several such questions - if so, rank them and start in hardest to easiest. When the thorny parts are smoothed out it will be much clearer how many parallel streams you can get going on the rest, and where the checkpoints have to be. But most importantly, you don't spend two months carefully setting down the interface structure, database structure, input validation rules, program flow and what have you to simply find out at the end of it all that nobody figured out whether the central problem HAD A SOLUTION.

[JamesCherrill]

I agree with the above.
It's just that, apart from some very technical library stuff, the biggest question mark is always "do we have a complete and correct spec?", and the biggest answer is always "I'll tell you after I see the completed system". That's the reality of commercial development. Since I joined IBM in 1969 I don't think I've ever worked on an application that didn't have a solution, or one one with a complete correct spec. :) That's the why my previous answer.was what it was.

[Reverend Jim]

I strongly recommend starting with the user interface. In my experience, it doesn't matter, from the user's perspective, what's under the hood if the part the user sees is confusing or just butt ugly. Yes, the hidden stuff is critical, but the customer will likely refuse anything that

1. Doesn't please the eye
2. Makes them feel stupid

An interface that makes the user feel stupid is an interface that has failed. With prototyping, an interface is generally easy to create (of course, the prototype will not have any business logic behind it) and a little back and forth with the user will generally allow for some tweaking early in the design process. I did this for one major software project (a Load Advisory Program for optimizing generation and transmission of high voltage DC power). Once I had approval from the users for the mock up I was able to program the guts. In a lot of cases, there will be "gut" modules that you will be able to develop in parallel that will be required no matter what the UI design ends up being.

I highly recommend you read About Face 3: The Essentials of Interaction Design by Alan Cooper, Robert Reimann, and Dave Cronin.

[Dani]

I use CodeIgniter, a loosely MVC-based PHP framework where models are "optional".

When I began coding the current iteration of DaniWeb, I began with some of the basics of the infrastructure. I first focused on the model layer and built up the essentials of what a post looks like, what a thread looks like, what a forum looks like, and what a member looks like.

From there, I created a bare bones crontroller, and focused on the view. As I built up the UI, each time I needed a new getter or setter, I built that functionality into the model layer. Each time the UI called some other type of behind-the-scenes behavior or functionality, etc., I built it into the controller.

I did that for the top three pages: Forum listing, forum thread, and member profile.

By the time those pages were done, which means they had a usable UI and basic functionality, I had a pretty sophisticated back-end infrastructure to support them. From there, I was able to build up the rest of their features as well as all the other pages focusing mostly on adding controllers and views.