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?
I would also go for Camp 2. What happens in Camp 1 if a department needs to change it’s name?
We used to encode our Dept name in our namespace.
Until we got renamed.
Not once, but three times.
What a PITA.
We still have references to (BofA.)
MTIWPE (Windows Platform Engineering)
MTIWSPE (Windows Server Platform Engeering
GTIWSPE
GTIWPD (Windows Product Design)
Now our namespaces are BofA.IISSupport.
The interesting thing is that our OU in AD is DS, which is the name of the org 4 renames ago. THIS WILL NEVER CHANGE 🙂
Hi Chris,
Interesting note about the AD reference. You are right, that name will never change. Interestingly enough, it doesn’t need to. The folks who manage the AD know that it’s arbitrary anyway, and they make the ‘mapping’ in their head. No one else sees it.
Perhaps namespaces should be similar. We pick an arbitrary name and stick with it, no matter what. We don’t show it to anyone else, so no one else will care if it doesn’t keep up.
Hmmmmm……..
Another argument for Camp #2 is if the support for the application changes teams. Though Team #1 no longer actively supports the apps, if Camp #1 is used, you’ve now got of date references that go beyond a team rename.
I think most architects would sit comfortably in camp #2. It meets so nicely with our processes, and is likely the more sustainable solution. Associating code (or for that matter, hardward) with people is, IMHO, always a mistake. It’s easier to map responsibility for a process or code area to a current maintainer than to recall an org structure 3 years down the road.
I’m clearly misunderstanding something here.
I’d have thought the namespace should capture the behaviour/responsibilities of all its antecedent namespaces.
Camp 1 sounds ridiculous to me (which is why I’m sure I’ve misunderstood – this wouldn’t be a discussion if the subject was as I think is).
Camp 2 sounds a little less weird, perhaps because I’m not sure what, "Business Process," is in this context.
To give a counter example: suppose you have an MVC application. Then surely you’ll have three namespaces:
com.ms.someapplication.model
com.ms.someapplication.view
com.ms.someapplication.controller
Now suppose this application will have a GUI interface and a command-line interface, then you may expect view to be further decomposed:
com.ms.someapplication.view.gui
com.ms.someapplication.view.console
And let’s say your GUI is quite complicated .. sorry, "Rich," such that graphical components can be manipulated and various topographies displayed, then futher namespace decomponsition might be:
com.ms.someapplication.view.gui.window
com.ms.someapplication.view.gui.manuipulation
com.ms.someapplication.view.gui.topography
All this namespace composition reflects the various responsibilities of the namespaces themselves.
I fail to see where coding-teams and business processes enter the picture. (Unless the gui is a business process, for example.)
.ed
Hi Ed,
You preceded all your namespaces with COM.MS.SomeApplication.
We have over 2700 internally written applications.
It is not sufficient to give them all a unique name called ‘SomeApplication’. Your standard puts them all at the same level.
That’s nuts.
So we create an additional layer of heirarchy to differentiate the applications from one another.
Your question implied that we would put namespace variations within an app. Not true. Your description would be fine within the app. It’s the stuff that goes ‘before’ the app in the namespace tree that triggered the discussion.
Ah, I see.
Thanks for the clarification.
.ed