Design – What do we mean by “design” in software engineering

You found a flaw in your development process. When it's a pain to do the right thing (create the table, repo, repo tests, flatten tests...), developers will find a way around it. This usually involves doing the wrong thing. In this case, it's tempting you to treat application data as application logic. Don't do it. Instead, add useful automations to your development process. We use CodeSmith to generate the boring, boilerplate code no one wants to write. After we create a table, we run CodeSmith and it generates the DAOs, DTOs, and stubs out unit tests for each.

Depending on the technologies you're using, you should have similar options. Many ORM tools will generate models from an existing schema. Rails migrations work in the opposite direction - tables from models. Meta-programming in dynamic languages is particularly strong at eliminating boilerplate code. You'll have to work a little harder to generate everything you need if you have a complex multi-tier application, but it's worth it. Don't let the feeling, "wow, this is a pain in the neck" stop you from doing the right thing.

Oh, and don't store your data in a format that requires additional processing (CSV). That just adds extra steps that require your attention and testing.

Obviously they are both wrong.

The bottom up guy is hacking away at code and will never produce something that does what it is supposed to do - it'll be a continual churn as the unknown requirements are determined.

The top down guy can spend just as long on architectural vision and get nothing productive done too.

However, a middle ground is ideal - if you know the goals you're working towards (which you get from a broad design work) and get on with coding it (without any detailed planning) then you reap the rewards of a system that is both organized and efficiently developed.

It's called Agile by the way (not the BS version of agile that some people practice where procedures are more important than working software) but true agile that gets on with working towards a commonly-described and understood end goal.

To fix the problem here, try an Agile approach (Kanban is probably the best) which will both force the top-down guy to do some work, and will force the bottom-up guy to do planning on what he's trying to achieve.