Where to start a new program
Here as an interesting question that popped up at my user group meeting last night, when you are starting a new program (green field development), where do you get started? I find these questions interesting because there really is no correct answer, but a persons answer will tell you something about how they problem solve.
Depending on who you ask you will likely get one of two answers. If you are talking with a data guy, he will say to start with the database. If you are dealing with a visual guy, he will say to start with the UI. Historically, I did a conglomeration of those two ideas, creating both the UI and the database at the same time, letting the two drive each other. But I’m weird, I’m a visual/data guy.
Lately though, I’ve started to thing about a third approach. Starting in the middle. No UI, no database, just the data classes. This approach has been spurred on buy a couple of things. Namely, test driven development (TDD), design patterns, and domain driven design.
TDD really is the glue that allows all of this to happen. I can start in the middle because I can run the code in the middle any time I want. I just have to write a test. No having to wade through multiple layers of UI to test out some small chunk ok UI is a great productivity gain for me.
Next is design patterns. This is what gives you a reference for how to approach your code. That said, this isn’t about making everything absolutely perfect from the get go, but it is nice to know where you are going to made your comprises early on.
But all of that does not explain where I begin. That is where Domain Driven Design (DDD) kicks in. For those not familiar with the concept, you can read up on wikipedia, buy The Book, or buy one of the various other references. One of the concepts in DDD (I’m still reading the book) is setting up something called a ubiquitous language.
The ubiquitous language is actually trying to solve a problem that I have seen happen on many projects I’ve been apart of (but not always my fault). At some point there is a linguistic difference between the nouns that the customer uses and the nouns that the programmers use. By focusing on the language first, you are attempting to head that off at the pass.
These nouns consist of your domain classes and your tables and columns, they move everywhere…but not always consistently. Consistency does matter. Inconsistency is what leads to rather confusing conversations with people and everyone scratching their heads about “what just happened”. So, this is the middle that I start with.
But before you start…
One of the other guys in the group was an actual data guy. The systems he has written worked with more data than yours does. Trust me on that. Historically, his biggest consideration was data input speed. I don’t think I would start in the middle if that was my biggest concern. In that case you do start with the database, you tune for speed. You also don’t use as many domain classes, and you tend to throw away your ORM solution and just hit the database layer directly via Ado.Net.
But lets face it, that doesn’t happen very often. Most business applications aren’t going to touch what the architecture can take. It is amazing how many horribly written applications with very inefficient code run just fine. Most of my speed issues could be solved by indexing tables and changing generic lists to generic dictionaries (more on that later). Architect your applications for how they are going to be used. Most of my web applications have a max usage of 100 simultaneous users. If the data access is slightly slower I’ll take that hit for programmer efficiency. If you are designing Amazon.com, you code for through-put.
OK, someone is going to disagree with this…I can already feel it. Please take a moment to register your displeasure in the comments. I would love to hear it.