Category Archives: Software

Debugging Home Run – Problem Step Recorder in Windows 7


I just got an email about a really cool new tool built into Windows 7 that Microsoft used to debug their new platform. It is called Problem Step Recorder. The best thing to do is to post a snippet of the email right here. I think it says everything perfectly:

“In case you’re not aware of this, here is a little known Microsoft tool bundled with Windows 7 that can be extremely useful to illustrate a problem when testing an application. The diagnostic tool called “Problem Step Recorder” was originally produced by Microsoft during the development of Windows 7 Beta to assist their Quality Assurance team in debugging the OS. It uses a combination of screen captures with mouse tracking to record your actions and can be a great way of describing a problem to others. The program is launched from the Start menu by typing ‘psr’ or ‘psr.exe’ in the search field. You’ll get a floating applet that looks like this: When you hit the Record button, the applet tracks your mouse and keyboard input while taking screenshots that correspond to each new action. When you stop recording your session is saved to an HTML slide show that recreates your steps. It also allows you to add comments to further document the problem. I think it can be very useful as an attachment in [your bug tracking tool] for those hard to describe issues or as a “How To” document for end users.”

Which leads to other ways of doing this… you could youse WebEx or Windows Media Encoder to document any bug as a step-by-step. If you use WatiN, Selenium, or VS2010, you can also use their recorders to document any bugs you may find in a web application, hand that to the dev team, and then there is no guessing how to reproduce the bug.

Kudos to Microsoft, and to the folks who uncovered this!

Software Metrics

Being able to measure success for a software development group is a difficult thing. But not being able to show the success of your development group is a dangerous thing. Your management team will want to be able to measure quality, show improvement, and benchmark against industry standards. All the popular maturity models (if you put stock into them) emphasize the ability to measure, react, and improve your quality and processes. My department is no different. We try to remain as flexible and lightweight as possible, and add formality where improvement is necessary. Here are some of the metrics that we collect to measure our success and find ares of improvement.

Code Coverage

There will always be bugs. No matter how hard you try, there will always be bugs in your software. That does not mean that you cannot try to prevent them. One of the easiest ways to do that is to write automated unit tests to validate your code is doing what is expected. You can write your unit tests lots of different ways, and Steve Cornett’s Code Coverage Analysis paper gives lots of different ways to break down code coverage. A great place to start is to aim for 50% coverage of all of your lines of code. And, as Tony Obermeit says in his Code Coverage Lessons paper, your ultimate goal of course is to always hit 100% coverage. You will need to pick a code coverage tool to help measure your success. In my department, developing in a Visual Studio and C# environment lends itself to the nCover open source solution. This solution works well with our CruiseControl environment. Test Driven Development methodologies and mocking tools can help you get closer and closer to covering as much of your code as possible with automated tests.

Defect Tracking

I use the words defects and bugs interchangeably. This I am sure is something that some people would disagree with, but I think that it is close enough. If it is not working as expected, then it is a defect, and it is a bug. Regardless, defects are identified in the development process, system and user acceptance testing process, and in the production environment. The objective is to minimize the number of bugs that are found in the live environments. To do that, you need to encourage the identification and mitigation of bugs in earlier and earlier stages. This sounds fundamental, but becomes difficult to implement. There are lots of methods that you can do to identify, solve, remove, and prevent bugs. You must have a way to measure that these methods are improving your success rate. And that means measuring the number of defects found in each environment – development, system test, user acceptance test, and production. The easiest set of numbers to get in a corporate environment is production defects. There is always a problem management system or help desk that tracks these kinds of things. But as a software development organization, you need to implement bug tracking throughout the entire lifecycle of your software. You can trend the numbers, and make sure you are finding more bugs before UAT, particularly in development. Tools like Bugzilla, an open source bug tracking tool, can help you track, trend, and manage defects in your software throughout its lifecycle.

Support Ticket Management

Software is not a static entity. It is always changing. Just think of all the patches, updates, service packs, and bug fixes that Microsoft releases on its suite of software. In a corporate environment, it is no different. Software management does not end once it is released. Teams of developers will be constantly updating desktop, web based, and console applications based on new requirements and requests from their clients. Problem Management software can be used to help track and trend all of these requests bydata points such as severity (Urgent, High, Medium, Low), priority (Urgent, High, Medium, Low), assessment (Customer Assistance, Required Modification, Elective Enhancement, Break Fix), difficulty (High, Medium, Low), etc. You can measure success agains more complex metrics such as the number of tickets created, number of open tickets, time to resolution, etc. All of these metrics will help you determine how fluid, stable, usable, sustainable, and maintainable your software is. Do not ignore your software or its users once it is released to production.


Web Analytics tools can tell you how many users you have had on your site, how long they visited, where they came from, where they went, how they found your site, did they reach your goal pages, did they convert, and did they return. There are free web based tools like Google Analytics, and over the shelf packages like WebTrends and CoreMetrics that can help you measure site activity. Do not ignore these metrics to help you define current activity, make improvements to your site, track your new results, and continue to improve. They directly measure your clients’ interaction with yoru software, and can identify trends that with simple changes can vastly improve your software and development processes.


So… these are some of the ways that we track the success of our software. There are a host of other methods to measure software, such as function points, lines of code, complexity, interfaces, velocity, etc. What ways do you measure your software? how do you define success? What are your plans for the future?

Leave me a comment and let me know what you think.

20 Reasons Why DHTML Layers are Bad

A bit of background before I dive in to the post… My team and I are responsible for developing and supporting the Brand web sites for Bristol-Myers Squibb.  The Brand Teams and external Marketing Agencies develop a concept for their site, and they deliver a fully functional version of the site in  HTML to us to implement.  We take that HTML, squeeze it into our custom content management system, and hook up all of our custom features.  This custom content platform that we call LaunchNet has built in registration management, site search, web analytics, SEO helpers, and a full suite of other tools. 

With an environment like this, managing expectations becomes essential.  Sites need to be streamlined for industrial-strength campaigns involving thousands of concurrent users and possibly millions of site users per month.  From this perspective, DHTML layers is one of the banes of development.  I have broken out why DHTML Layers make me lose my hair into 6 categories: Performance, Metrics and Analytics, Accessibility, Implementation, user Experience, and Search & SEO.


When using DHTML Layers, your users are now loading multiple pages combined into one, some of which they may not even view, wasting download time and bandwidth.  Pages are slower to download, and are slower to draw inside the browser.  Processing is now heavier on client side, and is heavily dependent on JavaScript, which is known to be a memory hog.

Metrics & Analytics

Layers are not pages.  This is a simple fact, but needs to be stated again for emphasis.  Layers are not pages.  This means that anything that is dependent on the construct of a page will break.  Google Analytics tags, which are designed to fire on page load, will need to be re-engineered to fire on layer loads instead of page loads. 


Mobile users on phones, PDAs, tablets, UMPCs, and other lightweight devices with web browsers will have difficulty.  These browsers are slimmed down versions of their bigger brothers, and do not have all the functionality needed to process JavaScript properly.  Cross Browser Compatibility is very difficult to implement and maintain with DHTML Layers.  You cannot bookmark a layer, either, so your users will not be able to come right back to where they were.  Popup blockers may block the use of DHTML layers, as this is a common delivery mechanism for advertising.  And, DHTML Layers could affect your site’s handicap accessibility.


Layers on the site increase complexity, and make maintainability more difficult.  If JavaScript is turned off, any functionality to show or hide layers will not work, so your users will not see it.  Developers will need to spend lots of time to make DHTML JavaScript function with content management systems, particularly when custom functionality is delivered in this way.  And, if layers are big enough, scrolling can become an issue, as the layers may run off the page, hiding content from view. 

User Experience

User Experience is the biggest reason to implement DHTML Layers.  It adds slick new interface to the hum-drum of static pages.  But designers need to keep in mind that performance impacts user experience.  This is an “I want it an hour ago” generation, and waiting even 10 seconds for a page to load will mean your users have left and gone somewhere else.  Layers are a not a standard UI convention for web development, and some users may be intimidated by the change in interface.  And, some folks may perceive layers as “popups”, which is bad for perception.

Search & SEO

Implementing site search while using DHTML Layers is very difficult.  Most search products are page based, and as stated before, layers are not pages.  Your content might not get crawled, or may be crawled incorrectly.  Layers could also cause a problem with search engines.  Your page could end up not getting indexed, or not indexed properly.  Invisible content may also be viewed by search engine crawlers as “gaming the system” or a black hat SEO practice, and may negatively impact your page rank.


When implementing, DHTML Layers, think twice about the impact on other aspects of your site.  Ajax can do a lot of the same kinds of things that DHTML Layers can.  Adobe’s Flash and Microsoft’s new Silverlight products can also deliver great new user experiences.  All of these have benefits and drawbacks that need to be weighed before jumping in.  You may be providing a slick new experience to your users, but you may be creating more problems than it is worth.  There are lots of other alternatives to explore.

My Most Useful Programming Development Tool Ever

The most useful development tool I use makes me more productive on lots of tasks all day long.  I can open just about anything I am working on, and get the job done fast.  It applies colors sparingly to my work, and helps me identify mistakes.  It helps me multitask, working on many things at once.  It understands dozens of different languages with ease, all at the same time, and you can add more very easily.  It has all the qualities of a developer who embraces open source solutions – it is fast, cheap easy to use, and available for download any time on SourceForge.  I have tried its competitors, but this one stands out among the crowd.  It was recommended to me by a colleague, and switching over was very easy.  My most useful programming development tool ever is Notepad++.  I have used the standard Microsoft Notepad, and I have used TypePad, but Notepad++ is head and shoulders above the rest.  Give it a try.  You will convert too. 

Disagree?  What is your most useful programming development tool ever? Leave a comment and be heard.

On The Road to Mix ’08

I consider myself blessed to work for a company I believe in, and in a field that I love.  Working in the field of web development is exciting.  The job is never the same.  The technology is always in flux.  Tomorrow will be different than today.  Bristol-Myers Squibb has treated me well.  And they are doing it again.  I am now scheduled to attend the Mix ’08 Conference at the Venetian Hotel in Las Vegas from March 5 through March 7. 

Mix 07 was a fantastic conference, and Mix 08 looks to be just as great.  Steve Ballmer and Scott Guthrie will be keynote speakers this year.  The sessions look really interesting.  I am hoping to attend the MVC session from Scott Hanselman, some of the Web 2.0 panels, some SharePoint sessions, .Net 3.5 demos, WPF and Silverlight sessions, and some of the UI discussions. 

Last year I documented my trip with blog posts after each one of the sessions.  I hope to do the same this year.  I was criticized by some of my peers last year that my blog posts from each session didn’t really count as individual posts (we have a performance objective to post a specific number of blog entries per year) but as one giant post.  We will see if my online trip report creates as much of a stir again. 

I am really looking forward to Mix again this year.  Take a look at the sessions, and let me know if there are any that interest you.  I can try to attend, attend, and bring back as much information for you as I can.

Netscape is Dead, Long Live Netscape!

Well, it is official.  The once-popular browser, from Mosaic through Netscape Navigator and all of its Mozilla variants, fought in the Browser Wars from 1994 through 2008, and is now throwing in the towel.  My once-favorite browser has finally fallen under the weight of Internet Explorer (and Firefox, too, I suppose). 

AOL announced on December 28, 2007 that as of February 1, 2008 they will no longer be providing Netscape Navigator.  Oh, how the might have fallen.  I found out about this on Engadget – Netscape finally bows out, browsers no longer supported, but you can read about it on the Netscape Blog – End of Support for Netscape web browsers.  The Browser Wars will continue, but without one if its original participants. 

The Lost Art of Debugging – Part 3 – Things To Do

As I have said before, debugging is a complex and time consuming process. I have outlined 10 resources for debugging, and provided a primer for things not to do when debugging. Now, we get to the meat and potatoes of debugging. This is a guide of things to do when debugging. I have broken this guide into three sections – a description of the Scientific Method of Debugging, Tips for Hunting for Bugs, and Bug Prevention Methods.

Scientific Method of Debugging

This is a parallel to the Scientific Method that you learned in your grade school science class. The book Code Complete by Steve McDonnell outlines this methodology to debug your applications.

  • Stabilize the bug by identifying the simplest test case that reproduces the error
  • Locate the source of the bug
    • Gather data about the bug and its behavior
    • Analyze the data regarding the bug
    • Form an hypothesis about the bug
    • Write test cases that would prove or disprove your hypothesis
    • Run the tests and prove your hypothesis, or begin again with a new hypothesis
  • Fix the defect
  • Test the fix with all of the new unit tests you have written
  • Continue to look for similar, cascading, or peripheral errors

For a more detailed breakdown of the Scientific Method of Debugging, read Code Complete by Steve McDonnell.

Bug Hunting Tips

These tips for finding bugs, broken out into different areas, will help you narrow down where your bug is.

General Tips

  • Be sure to save the original source code
  • Be sure the fix the problem, not the symptom
  • Make one change at a time
  • Check and Double Check your fix
  • Consider the possibility that the bug is generated from multiple sources
  • Divide and Conquer
  • Check other places where bugs have existed
  • Check other places where code has changed recently
  • Compile the application again


  • Insert Trace, Print, or Alert Statements to help track the bug
  • Create a logging methodology to trace the application
  • Check the Log Files of the servers, etc.
  • Search the web for the stack trace

Unit Testing

  • Design By Contract
  • Write unit tests that cause the error
  • Try to reproduce the bug in different ways
  • Try boundary cases and special cases

More Complex Methods

  • Recompile with a different compiler
  • Create a mini version of the application
  • Sequentialize the Parallel to see if it is a timing or resource issue
  • Try the code in different environments (local, dev, test, prod, other developers’ machines, etc.)
  • Grab someone else to talk through the bug without looking at the code (explaining the problem may trigger some ideas)
  • Do a full, in-depth code review on the broken code

Last Resort

  • Rewrite the whole section of code that is causing the bug
  • Take a break for a few minutes, or an hour, or until the next day, to give your mind time to process the data

Bug Prevention Methods

These are things that you should be doing during the planning and development of your applications that will help you identify, fix, and test your bugs after you are done with development.

  • Identify and track consistent bug types within your own code
  • Introduce debugging methodologies early
  • Implement loose coupling techniques
  • Implement Information Hiding Techniques
  • Write a regression test that tests the bug you just fixed

So… these are some different ways to attack debugging. Are there methods that have proven themselves that you have used? Do you take a different, more unique approach to debugging? What have your experiences shown to be your best practices? Please leave your feedback and let me know what you think.