When you use top-down programming, you describe the actions the app should take, and create function stubs (functions which act as place holders, but have no code in them other than comments) of those actions. Then you recursively interate through the actions those functions are to take and create stubs of those sub-actions. Once you get down to a very fine layer of granularity, you can actually begin filling in the code.
When you use bottom-up programming, you begin coding immediately, putting together functions as you need them.
When do you use which? It really, in my experience, depends on the complexity of the project. If you are writing a 25-line disposable perl script, top-down design will take longer than the 10 minutes for which you will need the app. If you are one of a team of 5 programmers working on a complex app that will take the best part of a year to implement, I guarantee you that you will use top-down methodology, if for no other reason than sharing programmer coding responsibilities.
A lot of the time, programmers really do an "inside-out" approach. They analyze the needs of the project with the idiosyncracies of the language in which they are programming and meet in the middle. Perfection in engineering does not happen when there is nothing more to add. Rather it happens when there is nothing more to take away.