Jaa

Should the name of a department be encoded in a namespace?

  • Artikkeli

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?

Comments

  • Anonymous
    November 29, 2006
    I would also go for Camp 2. What happens in Camp 1 if a department needs to change it's name?

  • Anonymous
    November 29, 2006
    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 :-)

  • Anonymous
    November 29, 2006
    The comment has been removed

  • Anonymous
    November 29, 2006
    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.

  • Anonymous
    November 30, 2006
    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.

  • Anonymous
    January 09, 2007
    The comment has been removed

  • Anonymous
    January 11, 2007
    The comment has been removed

  • Anonymous
    January 13, 2007
    Ah, I see. Thanks for the clarification. .ed