Wow!

Hey frob, please re-read my post because I gave plenty of exception and I feel that you took everything out of context. I don't have time to hit all the issues now, but I will cover one thing that makes everything that I said both happen in the real world "by preference" and is eventually available to every game developer.

The collection of software available to the leader of a game development company makes nearly everything practical, but only if the leader has the skills to use those software.

Taken in context, everything that I wrote is available and actually being done in the industry.

Well, what comes first is the artwork - It's because without the art work you can't move forward with the code. You can say artwork is the idea in which you will be going to write down the code for.

In the development of many AAA popular game titles, the artists went to work first in creating concept art, sometimes in illustrated scene by scene fashion. If it is done very well, then some of those artworks can be used for attracting more investors and for advertising the game once it is done. The more experienced the game development organization, then generally the more feasible it becomes to have a choice in whether to commit to some art assets first or to begin coding. Both could begin literally on the same day, as well. A highly skilled single person Indy developer could likely start with a 3D model or start with assembling some game source code libraries with a bit of coding.

If the first 3D model is exported from the 3D software in one of the standard model file formats according what the game engine will use, then this likely is no problem. One could begin to create a game that is very art asset driven from the start. To get a "map" or "level" rendered by the game engine would be an early priority so all art and coding can build in relation to it.

However, if already existing code libraries are to be used, then it could be preferable to tie these libraries together as a game framework upon which art assets would later be imported. Next, further coding would be needed to make game functionality and gameplay features. It is not unusual for placeholder art to be used until all fundamental game source code is ready.

Some game development companies have been blasted by gamers for using almost the same game engine, game functionality, and similar game concept in consecutive releases from the company. Here is a case where a company feels desperate for improved development cost to sales ratio. In this case perhaps all the basic coding is done and used as placeholder while the company puts new art assets in to the framework and will later add coding as needed.

In my opinion, most beginners to game development should start with coding first and add art assets later. An exception might be the highly skilled 3D artists who needs to build on a level that he or she has made.

My conclusion is that what is made first (art or coding) depends on factors such as personal preference, skill set, available existing framework, and business pressures.

We are going to outsource the artwork and the development, most likely to two different parties to save costs.

Based on my research, it seems the first time after the GDD would be to ask the programmers to produce the code for the game using placeholder art - e.g., square boxes instead of real graphics.

Then the next step is to send this over to the artist and ask him/her to create the artwork to fit the placeholders.

Once the artwork is ready, it goes back to the developers who fit it to replace the placeholder graphics.

BTW, placedholders can't be "empty boxes", it still needs some ugly art (forunatelly, coders draw them on their own in most cases). For example you can't code an animation without an actual picture of a human (with fifferent poses if we talk about 2D).

My advice would be ordering a finished game (corde+art+sound) and only do the marketing/publishing.