Recently, when on a trip to Tech Ed Barcelona (LINK) myself and Marc Popkin-Paine visited Multidomo, a home automation software company and Team System user in Madrid, Spain.  My contact in Multidomo is Luis Fraille who is a Microsoft MVP.  We visited their site to better understand their work environment and how they were using TFS to help with their application lifecycle.  This is a fairly long post so you may just want to read the overview at the start and conclusions at the end.

Overview

Multidomo is a software company that builds home automation software. It allows you to control various devices in the home from your computer or across the Internet.  There is a demo on the site where you can turn on and off lights and move blinds in the house.

The Company

This is a small business with only 2 employees, Luis and David (was 3 previously). They hire the services of a designer for some of the UI. The main office is just in the home of one of the employees. This home is also set up with all the home automation you could think of with lights, blinds, ac units, garden sprinkler, front door etc. all wired up with X10 or EIB protocol devices to allow them to be automated. The latest version of their software is always running in the house so they get self-host test regularly. There is also a web page where users can play with some devices in the house.

David works on a desktop machine that is also connected to the devices. Luis does all his work on his laptop and works mostly from David's home but sometimes he works in his apartment in the center of Madrid.

The setup at home consists of a server machine in the basement and a main automation machine in the top floor. There is also a media center PC in the living room. The system exposes some web services and these are hosted externally by a company in Miami, FL.

Software Overview

Functionality

There are multiple clients for accessing the system.

• A Media Center front end (client) - this is implemented in MCML (and was very difficult to achieve). The end result is a very slick and usable front end.
• A PDA client - this works on the smart phone or a regular pocket PC. It works very nicely when driven from the HTC touch. There are some ideas of future versions for Symbian OS.
• A web client - this uses Silverlight technology, Ajax and PSP.
• A web administration front end - this allows users to be managed etc.

These can list all the devices in the system and allow you to control them. For example, for web cams you can connect and retrieve the image shown on the camera. For blinds you can move them up, down, or some preset openings (25-75% open). 'Atmospheres' can be programmed which are named presets for the devices. For example, movie mode could dim the lights in the living room. There are also programs which can be executed through a simple workflow-like engine. For example there is a program for opening and closing the doors into the driveway. This is combined with a delay to implement open, wait, close. There is a simple interface for building sequences of actions.

Design Overview

The devices conform to X10 or EIB protocols for home automation. These are driven through an WCF web service which exposes all the operations for the devices. The client code provides front end and builds requests to the appropriate web services then interprets the results.  Communication is WCF throughout, except for some video appliances and some ASMX services for terminals not usable with WCF.  In those cases sockets are used.

Code Organization

They work off 4 different solutions and have one branch:

• A solution with 49 projects that contains all the client code. These are placed in solution folders and nested according to the component breakdown of the system
• A solution for the Media Center project
• A solution for the Silverlight project
• A solution for the database project
• A solution for terminals like mobile devices

Debugging

• For debugging Luis prefers attach to process for web projects (as he doesn't need to compile them usually).  For Media Center he uses attach to process since there is no other way.  For the rest of the projects he uses the traditional approach of F5.
• Luis uses the aspx design view to find the control then the properties page to find the binding.
• Luis uses (and likes) the visualizer for data set.
• Luis also keeps dbgmon open so that he can easily monitor the trace output whether or not visual studio is running.

VSTS Usage

• They use the source control for all code and are not branching.
• They are using the document folders and the Sharepoint site for their docs (there are not many docs).
• Architecture documents were created early in the design process (including UML sequence diagrams) but these were not kept up to date.
• They are using a modified SCRUM template and are very happy with the work items.
• They didn't think the supplied reports were very useful.
• They have many areas for the work items to quite a fine degree of granularity. They use the iteration field to track the product version and tag work items based on sprints. The sprints are numbered consecutively through a manual update of the appropriate work items (in sprint planning).
• When they had the designer doing work they created the work items and hooked up to Excel. The designer would then update the file and send it back via email for upload.
• Work item check-in policy is enabled so that all check ins should be associated with a work item.
• They use team build and have customized the build quality field to their needs (so they can indicate what has been done with the build: upload to main servers, upload new web front end only etc.)
• They are planning to use build retention in 2008.

Typical issue resolution workflow

When we visited they were starting some work to plan out the next iteration and reduce the backlog of work items.  The list below is typical of how they handle smaller issues.  Code is shared rather than owned although there is a concept of owner/author in that each person has areas that they worked on mostly and are the expert for but everyone touches everyone else's code and makes fixes in the code.

• Luis starts from the work items and looks at all the issues for all 3 people to pick up new work.
• Moves the work item to in progress
• Start debugging the issue
• Luis browses through the source files (rather than using find in files)
• Fix the issue and ad-hoc manual test
• Associate work item with check in
• Check in and launch build
• On build complete copy all to 'staging' file share.
• Manually deploy and verify
• Mark the work item to Done and ping David to verify the fix.

Issues

We saw a number of issues as we watched Luis work.  We are following up on these internally.

• In MSDN there is a lot of documentation and sample code for individual technologies but not for solutions. The samples are too narrow.
• In the media center part of the product they would like to stream the web cam. This cannot be done because media center markup is not supporting it.
• In media center it would be useful to customize the info menu for example to give a 'dim lights' option while watching a movie (instead of having to go to another menu system to get it).
• Silverlight install is clunky (compared to flash). If you implement a web site with Silverlight you risk the user abandoning trying to reach your content.
• In solution explorer with solution folder, if you nest them then the expand opens all sub-folders on first click.
• In team build, when you build it does a force get of everything. This really slows down the build process. Get takes 10 minutes for the large project.
• In the document window for Java Script (.js) files, the highlighting is very slow.
• MCML Pad is a poor debug and design experience compared to something integrated in the VS IDE.
• When there are 3 web applications in the solution, if you attach to one of them then the other 2 are started as well for some reason.
• After creating a profile of over 2Gb and then stopping the profiler and closing the project, devenv.exe was ratcheting up memory.
• When running a web test on a page that has Ajax, the browser doesn't show the page.
• Miscellaneous issues with recording a test on a page that has Ajax.

Conclusions

This is an interesting usage of Team System. Since the company is so small it seems that TFS would be more than is needed and overly heavyweight. Instead, Luis is a strong proponent of TFS and sees it as adding value, even in this small a company. Of course the source control is a significant feature that adds value even to one developer but also of value is the process template, work items and team suite tools.

By using the process template Luis was able to get started easily and customize according to the team needs. The result is a lightweight process and correspondingly lightweight work items - he never even opened the work item since the preview has enough space for his entire work item form.

With only 2-3 people they still get the benefit of the centralization of work and ability to track. This is particularly true when they include their contracted-out work in the list.  They easily and efficiently tracked the designer work using Excel hooked up to work items.

From the development and test sku they are using code metrics, code analysis, profiler (with a bunch of saved traces) as well as debugger of course. They also use web and load testing from the test sku and have found particular value in the DB sku from the schema diff tool. The checkin policy also helps them keep track of which change corresponds to which work item. 

Another big motivation for their usage is that they are starting to grow. Whereas now they all trust each other and liberally share code and have completely open checkins, in the future they will expand to a larger team and so Luis is keen to have the pieces in place for more control and tracking as soon as new people come on board. For example, he could create a private branch for the new hires to work in as they get up to speed or he could add more policy around check in such as requiring a code review or having code analysis rules applied on checkin.