Partager via

Dogfooding + Critical services

  • Article

My last post was actually going to be what this post is, but then i ended up getting distracted and figured that it made more sense as two posts. (This seems to be a fairly common issue when i write posts).

As I've already mentioned, I'm incredibly excited about Team System. Why? Because it seems to address pretty much every thing I need to do while writing software. So far I've seen that It has:

  • a bug tracking system, a source control system
  • a testing framework (both code and performance)
  • a project management system

Currently our team uses different products for each of these tasks. They're not integrated very well (except through adhoc solutions) and i find myself having to take care of managing propogation of a lot of data myself. The idea of having enterprise level implementations of this, along with strong integration into the IDE I'm using, has me standing here going "now! now! now!"

Howevever, there are some serious issues that I'm not sure how to resolve. The simplest to examine is the case of source control. Source control is an absolutely critical service that we need. There isn't a day that goes by where I don't actively use it and navigate the history of the source in our code base. It's not uncommon to need to go back several year sometimes (especially when I'm working on bug fixes for the code base that existed before I got here). I've heard from people in other companies that lost their source history at some point. Years later they were still realing from the loss. Losing this history doesn't necessarily have to come from bugs, but jsut from the natural evolution of the software. What if they introduce a breaking change into their schemas? It seems unlikely that they'll have the time to release a set of tools to take all my old work and put it into the new system. Of course, this would be required once we shipped, but it's unclear if we would get those gaurantees right now.

Another place where this is important is with my Unit tests. Unit tests are what I use to ensure quality and to allow me to change my code with the confidence that if i break anything it will be caught (and if it isn't caught then I'll just add a test to make sure it doesn't happen in the future). However, how can I do that if I can't trust the tests?

Are these services so critical that I can't dogfood them for the rest of the work I'm doing? Or are there steps that can be taken to make that possible?

Comments

  • Anonymous
    May 25, 2004
    In terms of source code control: sounds like the best idea is to ask the team responsible. If they did introduce a breaking change perhaps you could ask them to give you a day or twos heads up, which you could use to backup the existing client and data for a possible disaster scenario. The worst change I've experienced was moving from Vault 1.2.3 to Vault 2.0.0 where the definition of label changed. It broke many installations' usage of the product, but did not cause a loss of data itself.

    For the testing framework the best way to combat this is to use two testing harnesses. Perhaps nUnit and Team Services combined. More work? Possibly, but it would allow you to gauge nUnit directly against Team Services, provide valuable feedback to the Team Services team (ugh :)), and give you extremely valuable experience working within the Team Services framework itself. When Team Services was ready for alpha, beta, or prime time you would be ready with advice as to how to proceed. In situations where you must have a test and it must be reliable use nUnit or your current favorite testing harness. Struggle with the Team Service version later when you have more time.

    In the end it comes down to, yes, you can dog food them but it's going to take a little extra time to safeguard your data.
  • Anonymous
    May 25, 2004
    I'd like to see the ability to bind a test to a source control version. So I know that a particular version passed.

    The biggest problem I see is that most people think VSS/Source control is Change control, it is not... Change control is a much bigger thing than just having a version of a file, it incorporates reason, context and control.

    My 2 Cents...
  • Anonymous
    May 26, 2004
    I'm not sure if I should comment on this thread. I'm Cyrus' manager, so I get to decide what he dogfoods. It's hard for my suggestions to get on even footing. :-)

    For non-critical services:

    For technology coming out of your own feature team, always use the very latest. Never older than a week. (Cyrus' feature team is the C# IDE)

    For technology coming out of your product unit, use known good builds - typically a few weeks old. (Cyrus' PU is C# = { C# IDE, C# Compiler, VS Debugger})

    For technology coming out of the division, use alpha+ quality releases. (Cyrus' division is Developer Devision = { C#, VB, C++, CLR, FX, etc.})

    For technology coming from the rest of the rest of the company, use beta+ releases. (NT, Office).

    For critical services, bump them down one level. Wait for Release Candidates of the OS for your dev machine, for Beta of the CLR, etc.

    The other thing to do is make sure that teams closer to the devs are dogfooding before you do.
  • Anonymous
    May 28, 2004
    Does anyone at Microsoft use Source Safe? For anything real?
  • Anonymous
    May 28, 2004
    David: You should check the work the Team System team has been doing for VS 2005. They're working hard to make an enterprise level SCM available in the first half of 2005. You can read about it here:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsent/html/vsts-team.asp