Once you have your first set of requirements and design done where do you start programming? (Assume tests will be written in the same order, but before the code).
What do you suggest?
I work from the lowest level in the dependency chain to the highest. That way I can have something to compile and test early, and then I can build on it as I go.
I start with my Data Structures (DB tables, XTD, Data Dictionaries, etc) Then how the data will get into and out of said structures (Data Access layer) Then the Business Objects with their associated logic Finally, the User Interface and attaching those programmatic hooks to my business logic
I would tend to write and test the supporting framework classes first. I find that if I don't, I end up writing too much code before compiling and testing. Also, writing them first means that you'll be more inclined to make them full abstractions, rather than half-baked ones that are too incestuously coupled to the code using them. If you haven't written the higher level code when you write the supporting classes, you'll avoid accidentally introducing circular dependencies.
That said, when I'm writing the support classes, I will at least have already written snippets of code that show examples of how they are to be used in the higher-level code.
It must depend on what you are creating. I am working on a windows mobile application and started form the bottom up, working on classes and various data abstractions and then plugged it all together with a gui and it was a nightmare. You just can't show people (non-developers) code and convince them that you are 40% done, they need to see some sort of GUI. If I could go back, I'd mock up the GUI first.
But when it comes to data-driven websites, I start with the data purely because the web pages that allow you to manipulate them depend on knowing what the data will look like and how you might interact with it.
As an aside, I'm interested in "easiest" and "hardest" things because I think the natural human tendency is to think easy things will be easier than they are and hard things will be harder than they turn out to be!
I like to start by roughing out the UI.
That gets the discussion out of the way more quickly about how the design and requirements were all wrong (even if everyone signed off on them) and saves a lot of wasted effort.
This is a bit dangerous however, because most people assume that the UI is the bulk of the work and won't understand why it is taking so long to finish when the screens look almost final.
I almost always start with the User Interface. Once I know exactly what's coming in and what's going out, I find it easier to organize everything else.
It seems like everyone who's posted an answer to this question names a different place to start. The wide variation in starting points is a perfect illustration of where you should really start: wherever your ideal starting point is.
Different people have different ways of approaching problems. Often the success of a project is independent of the initial approach that one takes. Take time to think about and try different areas to focus on first and find out what's right for you.
EDIT: On a more abstract level, this article by Paul Graham offers good insight on a Lisp-style, bottom-up approach to programming.
Working with desktop/command line programs, I usually do what Ted suggested and start at the top (root) of the dependency chain (tree), in order to have something to test and compile early. I then add classes and complexity step by step down (up) the chain (tree).
Working with web applications I usually take a somewhat different approach:
I agree with the general consensus so far that you start at the lowest level, the data layer, of your application and build from there. To me it makes perfect sense because the business logic is built on top of the data layer and the front end is built on top of the business logic etc.
However, just considering one more thing - your customer. Unfortunately, the customer needs to see visible changes to know that you are doing something. And you will be surprise that even technical managers tend to fall into this mindset too.
So I try to make sure that at each iteration some thing is done to the UI as well, so in a sense the application is built in vertical lines. That is, some data, some business logic, some UI, show the customer. Repeat.
Personally, I think you should start with the domain model. This will, in large part, be pulled directly from your requirements, and will help you identify what pieces you'll need to create. Your domain model will drive your data model, and the requirements will tell you what has to be done to the domain objects.
Whenever possible, I'd start with a path through the whole app. Work generously with stubs. This helps to clarify the overall architecture of the program.
When that's done, I strongly recommend to work on the hardest part next. (Hardest part aka the most risky part aka the part where you have the least information about.)
Why? Because you need time to find all that missing information and if you cannot get this part working, the other parts have been wasted.
Re: Easy vs Hard item precedence:
I try to do what I think will be harder items first. This way if things go wrong, you're more likely to get and be able to give advanced notice. Also, if it turns out that something is unachievable, you don't waste you time on a bunch of small things that were dependent and are no longer needed.
The best place to start, imho, is with the data schema and then domain model and then any business logic between the model & the interface and then the interface.
Depending on the technology and development paradigm you use, it will serve as a natural extension of your business requirements into the coding world as it should, ideally, represent the bulk of your requirements.
Really, what you need to consider is what you're building, the design pattern you used to architect your solution, the relevant technologies being used and how they inter-relate (or not) and their dependencies.
Start with the piece that is the limiting factor - if you cannot build an adequate Domain Model without a data schema, then start with the schema.
If you have a rather intelligent database (all the tables, integrity and rules built into the stored procedures that do all the error checking and validation) with a rather ignorant middle tier (all it does is pass data along) design then the bulk of the work and the functionality lies in the back ....
If you have a rather simple database (just the tables and fields) and a very smart middle tier (all the logic, validation and integrity checking done here) ... the bulk of the functionality is in the middle ...
Now it's a matter of preference. I like progress so i start with the "easiest" thing to build - the "simplest" part of the application. For me, this helps crystalize the whole process at the code level for me - to see pieces falling into place at a relatively frequent rate.
BUT I ALWAYS leave the dazzly front-end to the last (or i get someone else to do it - which i'd prefer).!!
It's as much an art as it is a science ... every project is different unless you're just repeating a pattern with the same technologies and processes - in which case, bust it down to a science and make sure you take lessons away from each project so that you can compose a more efficient process going forward.
Cheers
I like to start by writing the framework, and then letting the other pieces fall together.
For instance, I will usually write a class which I know will be needed, then interface it once i have some desired functionality...then will carry on to the surrounding functionality.
I like doing things this way, because if feels like stream of conciousness, and when things are clicking it is very satisfying.
My take as a journeyman programmer:
When developing a Django application, I would define the models first, hack together some just-adequate templates, code the view functions and finish the remaining work on UI. All these steps inevitably overlap a bit (like making changes to Model classes while coding views), but this would be the general road map for me.
I prefer to start with the higher level (architectural) parts as they will better define what you specifically need at the lower levels. If you start at the lower levels then you usually end up bastardizing the higher levels to fit with the way you decided the lower levels should work. So in essence, you make your job harder by starting at the lower levels and your design becomes harder to understand. The higher level application code is the part that you want easy to understand, so it makes more sense too me to start there and ensure it works exactly how you want it to.
This usually means starting with the UI and adding functionality as the UI is built.
EDIT: If you don't know how something is going to work at the higher level you are working at; then create a method for that higher level piece to call and push the work off to the lower level modules. This does wonders for me in simplifying my code.