One thread of discussion going through our internal community is this: should the .Net namespace include the name of the IT team that created it? There are two camps:
Camp 1: Declare the Owners of the Code
We have a structure with about ten different IT teams, each assigned to different areas of the Microsoft business. Each team has a unique identity, and for the most part, unique standards. This camp wants the name of the IT team included in the namespace.
So if a project in the Services IT team (SIT, connected to Microsoft Consulting Services) creates an employee object (tied in the HR database), it may have the namespace of: MS.IT.SIT.Employee
If the Human Resources IT (HRIT) team were to create similar code, it would have the namespace of: MS.IT.HRIT.Employee
The reasoning goes like this: no matter how much we want to create code for the enterprise, the fact remains that a specific team will create the code and will continue to maintain it. Therefore, when using someone’s code, it is imperative that they are able to quickly and easily find out whose code they are using in the event of a bug or the need for extension. Therefore, the name of the owner should be in the code.
Camp 2: Declare the Business Process but not the owner
We have a centrally defined ‘business process framework’ that identifies a heirarchy of overall business processes, both primary and supporting. Primary process families are things like “Create Product, Market, Sell, Fullfill, Support” while secondary process families are things like “HR, Legal, IT, Finance”.
This camp says: put the process family name into the namespace, but not the name of the team. This will allow code developed by different groups, but supporting the same processes, to come together in the same heirarchy.
Back to our example. If the Services IT team was using the Employee objects to encapsulate services-specific rules, then perhaps the namespace for those classes would be: MS.IT.Support.Employee. On the other hand, if they were creating base code to access the HR database, those classes should be in MS.IT.HR.Employee.
The Human Resources IT team would use MS.IT.HR.Employee most of the time, since presumably, the rules they are implementing would cross all of the corporate employees.
The reasoning goes like this: The point of shared corporate code is that one team can rely on another for their knowledge. A single namespace tied to process families allows a more natural grouping of the functionality that we all have to rely upon. The ownership of the code is managed in a seperate tool. (note: the tool already exists for managing ‘who owns the code in what part of the namespace heirarchy.’ The .Net Framework team uses it extensively).
So, the challenge is, which namespace approach is better?
Personally, I think that Camp 2 is correct. Reasons:
- As long as we place the name of IT teams into namespaces, we encourage the development of duplicate code to do the same things. If I see my team name in the namespace, but no code to do what I want, I’ll feel free to add it, even if the same code exists somewhere else.
- Another downside to Camp 1: We would be encouraging the notion that “someone else’s code” is to be avoided at all costs. Developers will feel less confident about using the code from someone else’s team if they see their team name in the namespace.
- Organizationally, we won’t develop the needed muscles for managing a namespace of functionality that crosses multiple teams’ needs. The product groups do this, and MS IT should as well.
Of course, I’m just one opinionated SOB among a long list of opinionated peers. Convincing people of the value of one approach over another is going to take time. Whatever compromise comes out, I’ll support (assuming it allows healthy practices to grow).
What is your opinion? Should teams put their names in a namespace?