Barking Dog Gets The Biscuit

One of my favourite sayings is “The Barking Dog Gets The Biscuit”.  You may be more familiar with other phrases that convey the same meaning such as …

• The squeaky wheel gets the grease.
• The crying baby gets the bottle.

I like the barking dog variation because of the implication of persistence.  It’s not the fact that the dog barked once that led to them getting what they wanted, but the fact they kept barking that led to the reward.  The biscuit was important enough to the dog that they were prepared to invest the energy required to keep barking until they got their biscuit.

There is another well known phrase in computer  science, “Garbage In, Garbage Out” that we have all probably heard before.  In the Wiki definition, there is a sentence …

used to describe failures in human decision-making due to faulty, incomplete, or imprecise data.

… I have bolded the word incomplete to emphasise that Garbage In, Garbage Out can also be used to describe situations where the problem is the lack of input data.  It is not that the data is wrong, it is the fact that the data  has not been recorded  that leads to sub-optimal decision making.

When analysing what enhancement and issues to work on for a given release, amongst the factors considered are …

• how many customers have requested or reported?
• have any of the customers that have reported the issue given a date when they would like the issue resolved by?

The more customers that have requested an enhancement, or reported an issue, the more weight it will be given.  If demand is under recorded, then a task may not be worked on, when if we had the full demand captured we might move that task up the rankings.  Our Independent Software Vendor (ISV) customers will face the same issue when analysing enhancements and prioritising issues amongst their community, so will understand the rationale of why certain issues are worked on over others.

If a date required has been registered with a case then our teams can work towards that date when preparing their release schedules.  That might mean scheduling an issue for inclusion with a maintenance release, or if there is an element of urgency make sure the reporters immediate requirements are met with a Customer Controlled Release  (CCR).  What I find is that with ISV’s that have longer time periods between their own releases, they are better at giving a date.  They might say our planned release date is X, we therefore have a code freeze date of X – 2 weeks, give some room to test your next maintenance release, so therefore we need this fixed in a release by X – 4 weeks.  ISV’s with a more regular release cycle and Enterprise customers who deploy code fixes on the fly are more laissez faire, and tend not to offer a date.  They are more likely to work around an issue to provide a viable solution to their users quickly rather than waiting for a release, and then revisit the issue when the fix arrives in a subsequent maintenance or major release.

What can you do to make sure that issues that are important to you are delivered?

• Before raising a support case …
  • search the Issue Tracker to see if an issue has already been reported.
  • If you find the issue in the Issue Tracker and it is still outstanding, still raise a case in the Support Portal and ask to be added to the list of customers impacted by a particular issue.
• When you create a new support case, make sure your demand has been registered …
  • You need to make sure you have a product issue number, a product issue begins FGL, GAS, GDC, GBC, GST etc, a code that relates to the product. e.g. GDC-1234  You can look up product issues in the Issue Tracker.
  • If you have a case beginning SUP(region-code)-number e.g. SUP-12345, that is a support case.  A support case you will find in the Support Portal.
  • A product issue will be created by your support contact as a result of your discussions during the support case in the Support Portal.
• Make sure you give a date when you would like a product issue resolved by …
  • Allow time with that date between when we produce a release and when you would use that release in production.
  • Even if you have a workaround, indicate how long you are prepared to live with the workaround.
• Keep track of these product issues that relate to you …
  • Follow the issue progress in the Issue Tracker.
  • Note when an issues arrives in a maintenance or major release and verify that it resolves your case.
  • if an issue isn’t delivered in a maintenance release when you are expecting it, reopen the support case where you reported the issue. (Note: if our systems work as they should we should have already discussed with you before this happens)
  • if an issue isn’t delivered in a major release, participate in the Early Access Programs (EAP) so that this is captured and rectified during the EAP program.
• If an enhancement request you would like has not been worked on, discuss with other Genero developers you know, privately, or publicly in the forum, or in the Early Access Program.  What you may find is that other Genero developers have the same demand but it is unreported.

Our development teams do not have an infinite supply of resources and so like any other software development company we have to allocate our resources to work on particular issues and enhancements.  It is difficult to argue we should work on a particular issue or enhancement when the number of customers have reported the issue is zero or small, and/or no customers have given a date when they need this issue resolved by.