Archive

Archive for October 29, 2009

Error management: treat it as functional requirements

October 29, 2009 Leave a comment

Why is it so important to treat error management as just another category of critical functional requirement?

Because when the errors occur, it’s an opportunity to delight the customer – despite the very situation when the customer may be at risk of losing faith in the product.

Cryptic or confusing error messages can create significant doubt which can become its own fuel of further doubt.

Just imagine when the customer asks …

– “If this simple functionality is not working, what else may fail tomorrow?”

– “What’s the status of my payment?  I submitted the order and have no idea if the payment has been accepted”

– “What does ‘unknown error’ mean?  Who writes this stuff”

Or – the customer may react to a confusing error message and decide to take steps that may make matters even worse.

Let me paint another scenario that every VP of Sales does not want to see.  It’s a customer that provides a poor reference to a potential customer because they are very unhappy with the quality of the software.   The length of the sales cycles just doubled or tripled, delaying the sale and revenue recognition milestone (let alone cash).

That’s why it’s important to recognize error management as a critical functional element in design activities and subsequent design reviews.   Is the depth / complexity of the functional problem properly reflected by the error management approach?  I suggest to ask this question during the next design review.

I already hear some rumblings in the distance.  🙂  Who has time to do this?  Well – the cost of not doing this is even greater.  My last client was spending more than 60% of total engineering capacity on looking for the root cause of reported problems, instead of developing customer facing functionality.   Competition was more than happy to turn win-loss ratio in their favor.

I will be writing new blog posts about best practices in error management in the very bear future.

Stay tuned!

 

 

 

Defensive programming: move the concept from art to practice

October 29, 2009 Leave a comment

Few days ago, the nightly regression test suite completely melted.   There were so many errors that I had to schedule a very long conference call and work through the details and determine what happened.

Despite many errors, several distinct themes emerged from the discussion:

– The code did not have good run-time awareness.   Certain changes in the run-time environment (that could occur in the client environment) were simply not detected and caused unexpected behaviors

– The code did not have good error localization techniques.  Error that surfaced in component A was in fact rooted in a problem that occurred much earlier.    The code architecture made it very difficult to quickly find the root cause of the problem.

– Error messages were not descriptive not self-educational.  For example, there is a difference between stating “error happened while transmitting a file’ and ‘error during file transmission.  50 Mb of 100 Mb were successfully transferred.   Remaining 50 Mb will be transmitted when the service restarts in 3 minutes.  No user action required’.

– If the team spent on average 20 hours solving several problems, more than 70% of the time was spent on looking for the root cause.  The diagnostic time was simply excessive, a symptom of a poorly engineered code that does not generate helpful error diagnostic information.

I am a big fan of Code Complete by Stephen McConnell.  One can easily find it on Amazon.com at

Categories: Software Engineering

What to do when one fix creates 7 new defects

October 29, 2009 Leave a comment

This is probably one of the most stressful scenarios.

Major  software release is due at the end of the quarter.  The team is still fixing many defects and discovering that every new change is creating many new – previously undetected – problems.   It’s a difficult situation, one that I had to deal with recently while working with my client’s software engineering organization.

Step 1:  prioritize all defects and determine which ones are likely to be experienced by customers of the new release.   Some defects are very rare and occur under certain conditions.   Deal with these later.

Step 2:  delay the next release to create time for several important tasks:

a) Perform a deep-dive audit of technical architecture.    What is the ‘separation of concerns’?   In products where ‘separation of concerns’ is too close at the component level, it’s a very common occurrence to create multiple defects.

b) Examine regression testing strategy.   How much of the code can be automatically exercised by a suite of regression tests?   What’s the percentage:  40% or 80%?   How many critical functions are covered by regression tests?  How many critical customer scenarios (common & frequent functional paths) are also covered by regression tests?

c) Look for refactoring targets and accommodate refactoring activites in the next series of releases.  It’s very hard to stop and build a new architecture of a commercial software product while delaying customer facing functionality.  “On the go” refactoring is a way of life in a highly competitive market.

 

 

Categories: Software Engineering

Hiring product managers: questions to ask and detect a real gem

October 29, 2009 Leave a comment

I posted this entry on my old blog.   Since then I switched to WordPress.  But this topic seems to be very popular.   One of my clients asked me to strengthen their product management team.  Taking a product management team from ‘good’ to ‘great’ is one of the most difficult journeys.   Great product champions are simply in short supply – always.

Here are my thoughts about a great product manager, better yet – an exceptional product manager:

Is a convincing product champion. Exceptional product managers are excellent communicators who can engage the customer very well.

Is a visionary. It’s easy to say “we need to build X because customers A, B, and C need X”. It’s much harder to say and justify “we need to build X because X will open and create new markets”.

Is a crisp ‘distiller‘. Exceptional product manager distills customer pain points into a set of product capabilities that can help the customer in a measurable manner

There are of course many questions one can ask a potential product manager candidate. I will share some of the questions which proved to be valuable over time:

Product champion?
“Were you ever in the position to sell your product or explain its capabilities in a highly competitive environment?”
“If you lost the deal – what would you like to do differently next time?”
If you won the deal – why was your product chosen by the customer?”
NOTE: It’s important to look for the ability to lean from mistakes or losses. Champions are made, not born.

Visionary?
“Did you work with early stage products or were in the position to rapidly offer a series of very new capabilities not offered by any of the competitors”?
“How did you prioritize or select one capability vs another”?
“How did you position these capabilities to potential customers who have never even thought about them?”
NOTE: Look for a convincing and repeatable thought pattern when the candidate speaks to the customer, “this is a problem, you happened to have this problem, this problem can be addressed by these capabilities, which are only available in my product, and these are the metrics of success if you buy the product”.

Crisp distiller?
“20 customers want seemingly different things. Did you ever create a set of consistent of capabilities which answered 20 different needs in one release?”
“How did you do it?”

Exceptional product managers most likely read the book “Product Strategy For High Technology Companies” by Michael McGrath. It’s an incredible source of information about managing evolution of any product.

It’s always good to ask a product management candidate if they read any product management books lately and who they admire as a great product leader.

Categories: Hiring

Switched to WordPress

October 29, 2009 Leave a comment

Since Google acquired Blogger, I simply cannot reliably manage my blog.   WordPress – thank you for the welcome e-mail message.

Categories: Blogging, Hiring, Uncategorized