Product release reflections

We released a major update to our Milestone Tracking Matrix product this evening.  When release milestones are achieved it is important to reflect upon the good points as well as the areas where improvements are needed.  I’m tired tonight so I’ll simply share with you my scorecard for this release by including the e-mail I shared with the entire company:

“

   I wanted to take a moment and acknowledge one of the largest product releases we have ever delivered.  We met more than 30 customer-driven requirements, some small, some very large.  Not only did we meet these requirements but we also revamped the entire user interface so as to be much cleaner and easier to use, we delivered.  Our customers will benefit greatly.

   He is my quick scorecard:

• Customer Requirements: A-.  We met the vast majority of requirements, only falling short on some minor points.
• Scheduling: C.  While I take ownership for this one we must all seek to become more rigorous about upfront scheduling, tracking progress, and communicating challenges.
• Code Design Quality:  B.  We made some solid improvements in terms of code maintainability.
• Test Coverage. B.  We did a really good job but need to look at how to do a better job allocating resources earlier.  The challenge here is both schedule-based and resource limitations.
• User Interface Design: A.  We should be really proud of the work in this area, it feels like a brand new application.
• Usability:  Good usability improvements, customers will notice the changes we have made.
• Performance Improvements: C.  We only made minor performance improvements in most areas.
• Scalability: C.  We only made minor improvements.

Overall Score:  B

A great product release overall. We have plenty of room to get better, which is good….  If we did it perfectly what would we have to look forward to?

“

How does this compare to most of your releases?

John

Why are developers so bad at software estimation?

I read an article by Zeichick this morning discussing the reasons why developers are poor software estimators.  While I have my own strong opinions on the subject I would love to hear what all of you think.  I’m looking for opinions, not necessarily statements of fact so don’t hold back.

I’m looking forward to your votes and your comments.

Thanks,

John

p.s. For the record I do not think we’re really that bad at estimating software projects.

Morning Survey: What programming language would you use for a new web startup?

When I worked at Brainshark we would often explore this question together.  If we were about to join a brand new start-up, what language would we use to write the greatest software solution ever.  If you have a second, let me know what you think (by voting) and why (by leaving a comment. 

NOTE:  I have included Force.com after reading the following report.  The statistics are biased, I am sure, but still warrants consideration.

John

Brief technical tip, slow running JavaScript

I have been researching a problem where a very complex piece of JavaScript code is occasionally causing the very annoying warning which states “A script on this page is causing Internet Explorer to run slowly. If it continues to run, your computer may become unresponsive. Do you want to abort the script?”".  While developers have patience for this problem, customers do not, and should not, have to deal with this.

Since the error is only impacting one user within one customer installation I am pushing off a complete rewrite of the JavaScript until our next release.  However, this Microsoft knowledge-base article provides instructions for working around the problem on a machine by machine basis.  Here is the summary for how you change this behavior for IE 4.0 and above:

• Using a Registry Editor such as Regedt32.exe, open this key:
  HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\Styles
• Note If the Styles key is not present, create a new key that is called Styles.
  Create a new DWORD value called “MaxScriptStatements” under this key and set the value to the desired number of script statements.

I ended up adding the key with a value of 500000000 (5 Million) and the customer is now happy.

John

With ActionScript simple things remain simple

At Swimfish, as with any small/start-up company, I have the pleasure of working with people that are decathletes.  Everyone is capable of tackling tasks in a variety of areas which makes every day a true pleasure.

One of our talented support engineers has been helping out by working on a replacement for our small product ad that we show on our login page.  Essentially, we need to rotate between three product ads, with each of them looking something like:

Key points are:

• Every time the page loads we need to open a random ad.
• The arrows handle forward and back behavior.
• The numbers (below the phone) can be selected to move to the correct ad.
• The “Schedule a Demo” buttons open up a scheduling application that our sales team uses.

Here is how this simple Flash file was put together:

• Using Adobe Flash CS4 Professional my teammate put the images and text in place.
• To support starting on a random frame, we used two simple lines of ActionScript:

var startFrame:int = ((Math.random() * 100) % 3) + 1;

gotoAndPlay (startFrame);

          Using the modulo function to get the remainder of a number (plus 1) we’re able to generate a random number that ranges from 1 to 3.  We then use gotoAndPlay to start with that frame number.

• The ActionScript to handle the button clicks is very simple as well, looking something like:

btn3.addEventListener(MouseEvent.CLICK,go30);

function go30(e:MouseEvent):void{
 gotoAndPlay(3);}

     We simply apply an event listener to each button that is setup to navigate to the correct frame in the movie.

• The code that is used by the “Schedule a demo” buttons is only slightly more complicated:

anywherebtn.addEventListener(MouseEvent.CLICK,goAnywhere);
function goAnywhere(e:MouseEvent)
{var request:URLRequest = new URLRequest(“http://my.timedriver.com/GYXDM“);
navigateToURL(request);}

     Once again the button click is managed by the event listener.  The only difference is that we open a web page when the button is clicked, going to TimeDriver.com.

Let me know if you have any questions or comments.

John

A challenge of sorts, formatting phone numbers

As I noted elsewhere I have been focused on releasing a new version of our Milestone Tracking Matrix product, one of Swimfish’s leading applications.  One of the defects that I began looking into was related to how poorly we were formatting phone numbers within the application. 

Simply put, are requirements are that we need to show US-based numbers phone #s formatted as “(###) ###-#### x####”.    In other words, area code in parenthesis, the remaining 7 digits separated by a dash, and the extension formatted as “x” followed by the extension.  Fairly simple. 

Here was the function that we had in place (emphasis on HAD IN PLACE):

public static string formatPhoneAndExtension(string phoneIn, string ext)  {

    string phone = phoneIn.Trim();

   string formattedPhone = phone; 

    long tempPhone;

    if (phone.Length == 10 &&  long.TryParse(phone, out tempPhone))   {

                 formattedPhone = string.Format(“{0:(###) ###-####}”, tempPhone); 

     }

     if (!string.IsNullOrEmpty(ext))             {                 formattedPhone += ” x” + ext;             }

    return formattedPhone;         }

Phone numbers are entered in a text box with only minimal JavaScript formatting and have to work for a variety of numbers like:

• 978.223.1468
• 978-223-1468
• 9782231468
• …

While I have refactored and come away with something vastly improved I’d love to hear how others would have approached this function.  Anyone care to respond with better alternatives to what you see above?  The good news, you will only be making improvements.

John

Why is it that the best bugs are found at the end of a release?

It never fails.  I have worked with QA groups ranging from 1 to 100 and you always end up finding the most interesting, and sometimes the most critical, issues right at the end of a product release.   There are a number of reasons for this phenomenon, here are the ones I have seen most often:

• QA does not receive working features until the end of the release.  Release dates are fixed and everything comes together at the last minute.  We have all seen this and it always results in two things:  A mad scramble by all involved; A patch soon after the initial release.
• QA is properly staffed and works on “proper procedures”, developing robust test plans for each feature.
  • This is great, but sometimes leads to the basic aspects of features being tested with limited to no real world testing taking place.
  • Your QA team should be building test scenarios from the original business requirements and testing these as soon as they can.  If the customer can actually accomplish the the business tasks you were trying to automate they will be more forgiving of typos in a dialog.  However, they will not care that the product is free of typos if the core requirements have not been met.
  • You must build in time for random or freeform testing throughout the cycle.  Let your team be creative.
• Lack of customer testing.   QA teams do great but they are not your final customers.  Supplement developer and QA testing with customer beta testing early in the process.
• Unfortunately, many times, you also fail to test for performance, scalability, and security issues until near the end.  Ensure this is done throughout the cycle or you will have even larger issues to deal with late, when you least want to make these detailed changes.

John

Are you about to invest in Mobile Enterprise product development? You need to develop on the web first, here’s why

This has recently been a topic that I have been discussing with a lot of different people. In general, people tend to disagree with me until we talk it out.  Their argument is that the performance and the functionality available on each device is superior to what you can create with a web application. They are right on this front, but are still wrong in choosing to develop device-specific solutions first.

Here is why you MUST develop your mobile application as a web-based solution prior to considering device-specific alternatives.

• In the past, you could count on the majority of your mobile users (generally the sales team) to be utilizing Blackberry phones only. While there are incompatibilities between versions, for the most-part a Blackberry application for a lower version will work for higher versions(again, for the most part).  However, if you look at a recent article from Fast Company you will see that times have changed.  The data is for the United State only and will vary elsewhere. However, take a look at the numbers:
  • Nearly 50% of the users have iPhones with the remaining 50% fragmented between versions of the Blackberry, Palm, Samsung, etc.. I agree that many Enterprises reflect differing percentages, but the iPhone is gaining market share, you cannot count on selling mobile solutions that only target the Blackberry.
  • The data is also clear about the fact that Palm and Windows Mobile solutions are losing market share.  They are good platforms but users are choosing other devices.
• Engineers are expensive.  I know, I am one and I manage a team of engineers. With finite budgets you must maximize your investment to achieve the greatest revenues possible. Development of a web-based mobile solution will enable you to deliver an application that will work across the majority of devices used within the Enterprise today. There are small differences (don’t use JavaScript, for example, as it’s only available on the iphone and is limited there) but these differences will not prevent you from building a great solution.
• It is much easier to up-sell customers with web-based applications. You do not have to convince them to go back to your web site, buy, and download. They already go to your site to use the application and there is nothing to download. If they buy a new feature, it’s there, no hassle.

There are countless other benefits as well, ranging from control over sensitive data to detailed logging that you can use to determine which features are being used, and which are not, so that you can determine where you should continue investing your resources.

Now, I know I’ve convinced you, so now what? You will probably reach a point where you want to extend your application’s capabilities and need to deliver a device-specific solution. You need to carefully consider your current user base, of course, but be careful not to overlook where they are going. I’m currently using a Motorola Q with Windows Mobile. I love it and it solves all of my problems. When my contract comes up later this year, logic would dictate that I would  either remain with the current phone or purchase a new Windows Mobile device. It works, I like it. Guess what, I’m going to buy an iPhone and I know I’m not alone.

Have I convinced you? Do you see other benefits of building a web-based mobile solution first? Do you have reasons why you should build a device-specific solution first?

John
Follow me on Twitter

Unit testing, for better and for worse

For the sake of this post, unit testing is defined as testing the individual functions and code routines that make up your application.  You might be doing this manually or via automated tools.  The code you are writing might be part of the command console for a NASA mission, a stored procedure, or test automation.  Now that I have gotten those points out of the way…

You have to unit test everything you write.  It’s that simple.  Nothing, not even a simple one character change should be checked in or deployed without taking time to unit test the changes.  I’ve seen one line changes result in infinite loops taking down a web server in the middle of the day; it’s not pretty. 

How do I manually unit test my code?

It’s fairly straight-forward:

• Walk through every line of code in the debugger.
• Make sure your code is being called.  Early on in my career I once spent hours trying to figure out why a piece of code was not working, only to discover it was never being called.  That was a rookie mistake, don’t make it yourself.
• Examine the variables that are being set to ensure they are set as expected.
• Use watches to track variables that are not directly in the flow of your code.  Depending on the type of application you are working on they may be changing underneath your feet.
• If you have conditional aspects of your code, manipulate variables to ensure you hit all of your code paths.
• Make sure that callers of your function are able to work with your new routine or with the way you’ve modified an existing routine.  It’s easy to inadvertently introduce side-effects down stream and you need to be looking for unplanned changes.

How do I programmatically unit test my code?

 It’s time consuming to run through your code changes and it is easy to miss things if you are making changes to code that has been around for awhile.  Just as QA teams build automated test to ensure that the important, but tedious, test cases are covered on a regular basis, it is in the best interest of the development team to automate their own unit testing.   If you are going to automate unit test, here are some recommendations to ensure you are successful:

• Have a plan.  Define the requirements for what you will automate first.
• Set goals and define a schedule.  In one company I tried to keep the goal flexible, something along the lines of write a couple of unit test a week.  We rarely, if ever, met that goal.  Assign the task and measure it like any other project.  If you do not treat it as a priority it will not get done.
• Focus on calling those functions that scare you the most.  We all have those routines that exist in the depths of our code that no one dares to touch because if we so much as look at that code it will not ever compile again.  Automate those early.
• Don’t try to automate all of your unit testing.  Make sure your developers understand that they are responsible for the quality of the code they check in and that they need to test it manually before it’s checked in.
  • Some people do advocate test driven development (TDD) or automating the test after the coding is done and prior to check-in.   This is even better.
• Tie the unit tests into your builds.  Everytime you produce a new build of your code have the unit tests run. 
• If anything breaks put the team on alert and ensure the person that broke the unit tests is on the hook for fixing them.    Enforce this.  Keep your tests and build running cleanly and you will all be happier for it.

Have I missed anything that’s important inside your organization?

 John

Should you “throw it over the wall” or implement QA hand-offs?

As developers we often feel that our code is of high quality, that we’ve nailed the requirements, that we have unit tested to the best of our abilities.  We’re often wrong.

When I worked at Lotus, dozens of years ago, we once had a team that was convinced that there was no need for a test team, that developers following good coding practices and building robust unit tests could produce the right product, on the right schedule, at the right quality.  This team believed in the nonsense that I discussed in this post.  As I recall, the team never shipped a new product (after more than 3 years) and the team’s management was replaced multiple times.

In one of my recent roles I had a boss who felt that many of the QA-related processes that I put in place were overkill.  In his opinion we were generally better off coding quickly, throwing it over the wall to a formal, or informal test team.  Coding as quickly as possible without the overhead of too much QA time, was key.  I failed to convince this person of the error of their ways.    The end result was slower than desired release schedules at lower overall quality and a general dissatisfaction with what we were building. 

The right answer, which I implemented at Brainshark and that we are evolving towards at Swimfish, is the QA hand-off.

• What is it?  When a developer believes they are code-complete for some piece of new development they sit down with the QA person, and documentation writer, responsible for that feature or component.
  • They should walk through the feature and demonstrate that each requirement has been met.
  • They should raise any areas of concern they have with the feature.  Even after unit testing a developer may still have concerns that they need an additional set of eyes to review.
• What isn’t it?
  • It is not a technical design review.  While it is okay to discuss why technical choices led to certain areas of concern it is not a time to reconsider the approach.   It is the time to ensure that teammates understand what has been built so that they can perform system, performance, scalability, and other types of testing.
• What are the keys to success for the QA hand-off?
  • The developer should review the requirements prior to the QA hand-off.  It is not acceptable to come to this meeting without knowing if  you are “done”.
  • The developer should be done with all unit testing prior to the QA hand-off.
  • Documentation.  If appropriate, a one pager that describes any concerns the developer has with the feature.
  • Working code on the developer machine so that the developer can walk the teammates through the feature.
  • QA and Documentation teammates should come prepared, having an understanding of the feature requirements, not learning through the course of the meeting.
  • Defects will often be discovered through this meeting.  The developer should fix all of these items before moving onto the next feature.

Would this work for your organization?  Do you already do something similar?  Let me know what you think.

John