Posts

It’s bound to happen sooner or later. Every so often Scoble (Microsoft blogging wunderkind) posts something that makes me question his sensibilities. One of his latest posts stopped me dead in my tracks. The post was a reply to a Jon Udell post on UI technologies in Longhorn. I thought Udell’s post asked questions any professional should be asking. Scoble tries to bring it into focus by saying:

I have talked about our experimentation with XML as a file format. This is going very well. Since we started working with XML and its related technologies, other ideas started popping up. It’s not like XML is some magic concept, but it does open your mind enough to see other opportunities. Like creating a centralized Web Service to act as a repository for projects. You don’t need XML to do something like that, but since XML and Web Services go together, it’s easier to visualize how a service like that could be built off of (or into) our persistence system.

Developing new products is great for trying new things. There is no legacy and lots of freedoms. One of our areas that is screaming for experimentation is the UI. UI models have been changing in recent years. Many products are taking more of a Web-look. If you start digging into the design reasons, you’ll run across discussions of Task-based UI or Inductive UI. It’s not hard to find examples, especially from Microsoft: Windows XP uses Task Panes and Web-isms in many parts of the Shell; Office XP also makes heavy use of Task Panes; Applications like Quicken and Money have very Web-like UI’s.

The other day, some developer coworkers and I were talking about ways to make it easier for our Test group to create and maintain test scripts. Test scripts are a very important piece of the software development puzzle. But test scripts don’t find new defects. Test scripts are really good at finding breakage. That’s why scripts are run on new builds as BVT’s or release candidates as part of a larger regression suite. For me, few things are worse than uncontrolled breakage to keep a project from hitting deadlines.

How is it that a software development company that understands the value and importance of the code their developers write doesn’t place the same value on the code their testers write? Good development processes apply to tester too. Regression test scripts are the health indicator of the development process. Build Verification Tests (BVT) or Smoke Tests are very important and, typically, rely on code written by testers.

People who know more about software development processes than me, and write books on the subject, frequently talk about metrics like Defect Density (defects per thousand lines of code). Say your development team averages 10 D/KLOC. If you start working on the next version of a product with 1M LOC and eventually add 100K LOC, you could look into your crystal ball and expect 1K defects. Holy crap! Honestly, it could be worse. In my experience, adding code to a 1M line product is likely to break lots of the existing code as well.

In my last post, I talked about some persistence issues we are working through and how persisting to XML could make things easier for us. In this post, I want to talk about using XML as a file format. Assuming we switch to an XML based file format for our products, there are questions I have regarding the proper use of XML.