Dec 5, 2008

Expectations from external development teams

When you cannot influence technology decisions that an external team makes, what expectations can you set to still get a quality product?

- Code checked into a version management system (SVN, Git)
- Automated build/test/deployment mechanisms
- 100% test coverage (automated test cases)

These things will ensure the following for application -
- low cost of change
- easy transition to other teams
- easy support

Internally we track such attributes in a product scorecard that we review periodically. You've got one too, don't you?


  1. Good thoughts Prasoon, but with the advent of scrum we tend to forget the power of documentation during the product's support/maintenance phase. I guess just enough documentation must also be part of your checklist. Apart from the Design, this also includes business perspective

  2. While working with an external team, a few things we can look to develop internally so that all teams can share..

    - Publish recommended design patterns/ coding guidelines
    - Develop and share re-usable assets (can be anything to simple images to complex ORM functions)
    - Collaborate - Have a platform to discuss what different teams are doing

  3. Good extensions to the list Yogesh and LD. Thanks! Documentation shouldn't be ignored. We can and should share existing design patterns, reusable assets with such teams. We've tried to create a pattern library but lost steam midway. Yan and team are trying to revive it. Lets see how far we go in 2009...

  4. One addition to this list makes it more robust and almost guarantees delivery of good product...

    1. Code Analysis by tools.

    It can be automated like test cases!


  5. Sujeet, we haven't had much success with code analysis due to the signal to noise ratio. Ketan is playing with it in Java space. Can you share some ideas with him?

  6. sure will do.

    Here we are language independent and tool independent. So let me give some simple explanation for signal to noise ratio...

    A code analysis tool works by searching some n bug patterns in a given code base.

    Suppose we run the tool as it is..

    It will search the code and suppose it finds m bugs in it.

    The catch is not all of the n bug patterns are relevant and also we may not want to run the tool in all of the modules(like test module) of the given system.

    Hence after proper configuration, we may get m/4 bugs.(By experience i have seen this happening)

    Again out of those m/4 bugs, few are of high priority.

    Let us configure again and search for high priority bugs.

    After this we may get m/16 bugs.

    This number is very much managable.

    This reduces the signal to noise ratio.