Rob's Most Excellent Tape

In 2006, we were discussing ways to distribute small software add-ons that complement our current products. Rob Gingell, our CTO, talked about the "utility tape" that accompanied Solaris and other UNIX operating systems. The top utility was never part of the operating system by default, but it was found on "the tape." However, everyone used top, and top eventually found its way into the standard operating system distro.

So, the RMET, or Rob's Most Excellent Tape, was born! Now, we don't actually use a tape to distribute it, but the name was kinda catchy. (And I think Rob liked it.)

One of the first things that found its way to the tape was the Scripting SDK (SSDK). We needed a way to extend Collage functionality with small scripts written in a UNIX shell or Windows batch program. So, one day Mukund wrote the SSDK. It hid the complexities of the Collage Web Services interface and exposed a small and simple set of commands. The SSDK is now a standard product offering and even has its own documentation on InfoCentral.

The Java dashboard is another item that is found its way into the SSDK. Last year, we were giving a demonstration to the executive staff of a large company, and we decided that we needed a high-level dashboard rather than the detailed web UI. So, Mukund developed a Java Swing app that used the Collage Web Services interface to expose a high-level dashboard that showed how servers were allocated to different application tiers. His dashboard also showed servers powering up and down. Recently, the Java dashboard found a new audience with our Sales Engineers, and its now installed in a partner's executive briefing center in New York.

And a few months ago, Jason became a new contributor to the RMET. He developed a Reporting application that extracts data from the Collage database into an external data warehouse. Jason then used Active Grid to develop a reporting application that allows you to track server usage by cost centers. The reporting tool allows you to track depreciation and operating costs (e.g., electricity) by the cost centers you define. Since Collage allows you to allocate servers to applications on a dynamic basis, you can adjust the capacity allocated to each application. So, now you can have a centrally managed IT pool and charge back to different groups for their actual usage.

The RMET provides a convenient way to introduce these add-on functionalities. And one day some of these add-ons might find their way into the standard product suite-- just like the top you know and love!

Introducing My New Blog

With this blog, I've focused primarily on technology topics, with a particular emphasis on data-center issues. Well, I continue to keep this same focus in this blog. However, I've started a new blog that will focus on one of my hobbies. Most of my colleagues and friends know about my interest in the game of golf. (Okay, it's probably more than just an interest.) Well, along the way, I've managed to teach both of my kids the game, and my 8-year old is my regular playing partner.

My new blog, "Golf with Your Kids," will be a collection of experiences, resources and tips for enjoying the game of golf with your kids. Take a look at my introductory posting. And if you're a golfer, please check back on a regular basis. Fore!

What's in Your Head (of Tree)?

Head of Tree. Tip of Tree. It's your source code repository, where you check in your latest and greatest source code. Could you ship it to a customer at a moment's notice? Actually, would you ship it to a customer? I understand your hesitation. The latest code still needs to be tested. You have to shake out the bugs, and then beat the release into shape. And then after a stabilization period, you're ready to release-- probably weeks to months later, right?

At Cassatt, we switched to a new development process in PD at the start of the year. Head of Tree, or HoT as we affectionately call it, is always shippable. Asynchronous projects are used as the vehicle for developing new functionality or fixing bugs. Each project has a well-defined scope and is completely self-contained for completeness. When a project is launched, its completion criteria-- the required functionality, expected quality criteria, associated application payloads and documentation-- are all defined up-front. Only when the project meets all of its completion criteria, can it integrate to head of tree.

In this new model, a project can not integrate if it introduces new bugs or regressions. So, all projects must integrate with zero bugs. So as new functionality is introduced, the overall quality level of the head of tree is maintained. Since many projects introduce new automated tests in addition to new functionality, the overall quality of head of tree can increase over time.

Transitioning to this new process was a significant cultural change for the Product Development organization-- and it wasn't easy. Starting in the last quarter of 2006, the PD management team defined the new process and worked through the details. We flattened the organization and centralized decision-making to one Product Team. And there were many small bumps and hiccups along the way. At times, we were still working "the old way" in the new model, and we had to make a conscious effort to change. At times it felt like we were working more slowly in the new model, but we found that there were fewer missteps and almost no "steps backward" to move forward. And by slowing down, we took the time to review architectural changes to the system and understand their impacts. With each new project, we got better and more efficient at defining requirements, planning, developing and testing. Along the way, we developed new metrics and reporting tools to monitor the projects and the head of tree.

It's now been six months since we transitioned to the new model, and we have seen several tangible benefits.

1. New functionality can be developed and released to customers quickly. There is no need to "wait for the rest of the release" to complete.
   
2. Projects can be sized accordingly to complexity and/or effort involved. A "large" project can complete in 3-4 months, and a "small" projects can complete in 1-2 months. Simple bug fixes can be handled in a lightweight manner, requiring only a few days.
   
3. Requirements are defined and understood before starting development. We have even decided to not proceed with some projects because the scope was not appropriate or the ROI was not sufficient.
   
4. Development has become more predictable. We maintain an integration schedule for the next several months and let our Field know when to expect new functionality. The upcoming integration schedule is reviewed weekly with Sales and Professional Services.

In a future posting, I'll provide more details about the process and also talk about some of the metrics we use to monitor progress. Until then, have a happy Fourth of July, and stay safe!