I’ve had this brewing in my head for awhile now and wanted to share it with you, my fellow netizens.<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” />
This stems in part from a philosophy course I took back during my undergraduate days called “Freedom and Responsibility”. The basic question in the course was “do we have free will and, even if we don’t, are we responsible for our actions?” My final paper was an analysis of the sentence “I have free will” and comprised two basic sections. First, to determine the truth or falsehood of the statement we have to define “free will” and what is necessary to be free willed. Next and this is even more important, we need to define who or what the “I” is that [believes it] has free will.
I proposed that the “I” part was more important because, no matter what free will ends up being, the subject of the sentence is the creature affected and through whose perspective the whole question is posed. Changing the “I” inherently affects the “free will”, and so on.
You may ask why I’m bringing this up; does this have anything to do with Team Foundation Server? I’m so glad you [may have] asked.
Indeed, the same sort of analysis can apply to the very term “Team Foundation Server”, only in three parts. Let’s work backwards.
What is the “server”? That’s fairly straightforward, but has hidden complexities. In the simplest world, the server is the application tier, data tier, build machines, and proxy machines through which users access and manipulate “team foundation” objects (version control items, work items, work item queries, team builds, reports, team portals, etc.). Of course, if it were that simple, we wouldn’t have so many questions about setup and server configurations on the Visual Studio Team System forums. Still, those questions are mostly technical and less theoretical in nature. In the interest of remaining somewhat philosophical, I’ll defer those questions for a later time.
What is the “foundation”? Again, we can take the simplistic view that the foundation is merely a collection of tools (version control, work items, team builds, team portal, etc.). However, there’s more to it than that. The foundation is more of a framework or an SDK due to the project templates, object model, and publicly accessible web services [N.B. I’m not advocating directly interfacing with the web services here- they are intentionally undocumented as the OM is expected to be the major entry point for extra plug-ins]. These access points allow people to modify processes, workflow, and even work item types and project definitions. A framework is supposed to have some degree of open ended behavior capabilities, and that’s what we [hopefully] provide with the OM/template model for Team Projects.
Finally, which “team” are we talking about? What is a team? The way I see it, “team” is a many layered onion, if onions contained multiple sub-layers per layer (not that some don’t – I cooked one just the other night that— hmm, off track here). At the innermost layer, the team is a single person. Personally, I want to make sure to be thinking about what you, each and every individual using Team Foundation Server, need, want, and would benefit from on a daily basis. How can we help you be more productive? Around that is the group of folks including your direct coworkers and manager. I want you to be able to use TFS to tell what that team is doing, how it’s measuring up, and what its priorities are from day to day. Beyond that may be your feature group or product unit or sales team or… any number of things, really. You should be able to use TFS to find out what’s going on there, too. And up and up and up to the level of your whole company. How can you figure out what your company is doing? Where it’s headed? Hopefully, the answer will be “Why, used Team Foundation Server’s reports and queries, of course!” If not so today, then hopefully someday soon.
To me, as with “I have free will”, the key aspect of “Team Foundation Server” is what I’ll call the “subject” of the phrase. The “Team” should always be the focus of our efforts- how can we help your team, no matter how big or small it may be, get more done with less hassle and frustration? What does your team need day to day? What does it want? What could you benefit from that we haven’t even dreamed up yet?
If you ever think of an answer to one of these questions, please feel free to send it my way and I’ll see what I can do to help you out. I can’t control or predict the future of the world let alone Team Foundation Server, but I may just be able to nudge it along a bit, and sometimes it’s the butterfly flapping its wings that causes the storm.
Enough philosophy- next time we’ll get back to good old reliable TFS functionality posts. Cheerio!