Link Details

Silly advice by a wannabe expert!

I wouldn't go as far as he does to say that the data model should be left as late in development as possible, but I completely agree with the idea that growing software from the data model upwards a la RoR/ActiveRecord makes software difficult to use. The best (ie. easiest-to-use) software is focussed on the use cases. These are the things users understand best. The data model is a second-order abstraction invented by engineers and is of little interest to your average user.

You start with a data-model first, 'cause you want the data to be accessible by clients from different architectures.
The data-model is the basis common to all applications working with the data, so this has to be rock-solid. From there on you work your way to the application.

That's the way to do it. Nobody can convince me otherwise...

It's a really good advice. Starting your applications with a database schema (which many people do) is bad.
You need to focus on how the application will be used and what tasks will be performed.
Storing data is just a small bit you can sort out later.
You have to program to the interface, go from top to bottom, not the other way around.
People who don't get this usually have no clue about OOP, it takes some experience to get there.

"Storing data is just a small bit you can sort out later."

That really depends on the nature of your application. But normally I would say (at least in the field where I work), storing the data is a vital part. At least if you want to be able to scale your model (normalisation anyone?) and to do statistical reports on the data.

It's true that some applications are data oriented. If you build a reporting system the code it's just a way to extract the data.
But in most cases, database is just a persistence layer. It's just a means to store data, not a goal for your application.

Developers with even more experience know that there is no One Golden Starting Point, but rather you take successive passes with multiple artifact types.

Does a master carpenter always begin with a hammer or ruler? :)

Will the carpenter cut pieces of wood before he decides what he's building?
Database is resource, unless your a DBA, but then it's not your job to build software.

As always, the human compulsion to classify everything into a black-white enum. :)

Generally, given that *all* phases of development should be iterative, it doesn't really matter where you start, although some artifacts lend themselves better to discussions with specific types of stakeholders. Always use as little as possible of a few artifacts/tools to help guide your software development in design, implementation, testing, etc...

Secondly, there are many problem with this blog post, stemming from a possible fundamental misunderstanding of the purpose of a relational data model. The article may have been written poorly, so I give the author a little benefit of doubt, but as it stands the author obviously sees the data model as a negligible after-effect of needing to persist objects, rather than a first-order construct that stores assertive facts about data. This is common in developers that have used too many ORM (object-relational mapping) tools without trying to understand the raison-d'etre for the Relation model. (Yes, relational with a capital R.)

Thirdly, just because users can't fully understand a full physical database diagram doesn't mean simpler versions cannot be presented. I often get real insight into domain issues when I simply present (actually, I like to use ORM (object-role modeling) for that conceptual effort.) table titles and the relations and review it with SME/stakeholders. "Oh , no, wait...sometimes we can have two clients involved in one note." Grumble. Erase. Grumble, grumble. Write in one-to-many instead of one-to-one. :)

There are other minor problems. For example: "A data model is a solution in the database domain not the problem domain." Huh? Someone needs an intro to the Relation model and what a relation actually is, a proposition or assertion of truth. It explains the problem space exactly in terms of data and even some "behavior"...

I could go on, but I won't. Be careful with this article.

Not in the real world where I work. Applications are to give users value, allow them to perform tasks, solve problems.
Some are data driven but usually the database is there because you just need to keep state.
If you job is just about building fancy interfaces for databases then I pity you.

You have DBA mindset. You're on the wrong site ;)