Programmers: Which tier do you start developing first?
Torn between which tier to start with? I pose this question to most of my interviewees and you'll never guess what a couple programmers have answered.
If you've been programming for a while, you know the different tiers for building an application from scratch. Everyone I've interviewed in the past were asked this question and it's more of a philosophical question, depending on how long you've been in the programming work force:
Based on the given tiers of development, which are defined as the Presentation (GUI), Business Objects (Business Layer), Data Access Layer and/or Database (Data Layer) itself, which tier would you start developing first if you were creating an application from scratch and why? How about converting a legacy application?
For those a little fuzzy on tiered development:
- Presentation (GUI) - Classified as a browser or cell phone (HTML), or a fat client (EXE written in either C#, VB, Delphi, or whatever).
- Business Objects (Business Layer) - How the system should be governed.
- Data Access Layer - Conduit used to connect the Business Objects and Database to provide data to the business objects.
- Database - Your Database server (mySQL, SQL Server, Oracle, Access, etc.)
Ok, go away for a minute and think about the question. Then come back to see what others said.
Back? Good.
Let me give you the answer of what a couple of developers answered. The tier they would start working on is the Presentation Layer. Ouch! Not quite the answer I was looking for.
Here's my take on it.
Starting from Scratch
Personally, if you are creating a system from scratch, I would start with either the business objects (Business Layer) or the database (Data Layer).
Here's my reasoning: The business objects should drive your validations and rules of the system, and if configured properly, changes can be made without recompiling your code. I've seen architects put validations and rules in the database so the presentation (Browser or GUI) would have to go all the way back to the database just to find out if a zip code a user entered was valid or not. I'd rather put the primary validation on the GUI with a "are there any letters in the zip code?" using JavaScript and then use the business objects to find out if its a USA or non-USA zip code. If everything passed in the business objects, pass it through to be saved to the persistent storage (Database, XML, Flat-file, etc.)
Another reason to start with business objects first is because it will define your requirements of the system. Hence, requirements gathering and object diagramming. If you don't have a solid path of how your objects will interact with other objects, you may have a flaw in your design.
The final reason to focus on the business layer first is actually a combo deal. The business layer coupled with a well thought-out designed database have extremely powerful combinations. If you have these two tiers already defined and running optimally, you can provide any, and I mean any, presentation layer necessary to run your applications on any platform regardless of the client machine, whether it be a browser, cell phone, or fat client.
The other tier that would be a valid answer is the Database. Define your persistent mechanism of how your data will be stored. Is it going to be stored in an object-oriented database or a RMDB? Once defined, start building your tables at the ground level. The database should go through a prototype or draft phase, be analyzed, and then start moving towards a normalization process and should be constantly fine-tuned, even after the system has been implemented.
Legacy apps need a facelift
What if you were upgrading a legacy application? Which tier would you start first?
I'll leave this question open for the community to talk about and I'll follow up on this later this week with some quo
