I love working with teams when developing software. A solid team results in produces better end products due to the consolidated skills of the whole. One of the things I look for in the cultural mindset for a development team is a group ownership of the entire application. Each individual has areas of expertise. However, there is no portion of the application that belongs to any subset of the team. In short, all team members are responsible for all of the code. Because all are responsible, all are responsible to make changes anywhere.
In practice a team tends to take advantage of the strengths of individuals, while not making them individually responsible for the areas of their expertise. Instead, while they exercise their strengths, the decisions are tempered with the input of other team members, or the team as a whole.
I mention this because of feedback from yesterday’s editorial, pointing out the need for this very mindset. The issue was the dissonance between database design naming standards already in place and the requirements of the ORM generation tool for identifying a primary key by naming convention, which was different than the database naming standard.
Two options were possible. 1) modify the database naming convention, and modify existing databases to be addressed with the new ORM code. 2) modify the ORM code generator to synchronize it with the existing databases, and the database standard.
Either option is reasonable. Existing databases with data and constraints require more work, causing us to choose pragmatically to modify the ORM tool Since we made the ORM tool change, we didn’t modify databases still in design. But, that would have been an easy modification.
Regardless of your implementation, I do want to raise the warning of blindly allowing your business objects to define your database structure. Consider a database using natural, and sometimes composite, keys as a table’s primary key. This structure makes it more difficult to use some ORM generators without some tweaking. Net Tiers actually works with the internal schema, and handles this design with ease. Entity Framework expects a sequential numeric ID which is case sensitive. The point is that you give up some powerful database design considerations when you rely on code by convention such as Entity Framework.
Just as the readers left in the comments, the correct answer depends on more than just the opinion or preference of one individual. This is a good tension. If the team embraces the difference it results in a strengthening of the team, increased understanding of all, and a more powerful solution.
What is the culture of your team? How do you work through selecting implementation methods when there are differences from team members having different perspective? Share your comments. Get into the conversation.
Cheers,
Ben