When Would You Like This Fixed By?

When resolving an issuing and we have resolved that we need to provide some form of fix to our product, a question that we will ask is along the lines of “when would you like this fixed by?”  We are both in the software development business and regular issues are not resolved by stopping whatever we are working on, fixing an issue and then delivering it straight away.  There is normally some form of release cycle /  release procedure involving QA, and the new work needs to be scheduled in amongst the existing planned workload.

I tend to find customers are “too nice” when answering the question of “when would you like this fixed by”.  For example, if you are making some enhancement to meet new government requirements that come into effect on 1st July, your answer should not be “1st July”.  You may have some QA, parallel runs, code freezes that need to take place beforehand, so your answer should probably be “1st May” along with an explanation why.

I also find Independent Software Vendors (ISV’s) have different needs than Enterprise Customers.  ISV’s have their own production schedule, release cycles and so are looking for fixes that fit in with their own product release schedule and can normally be more accommodating.  For Enterprise Customers, there can often be more urgency as they can have a culture of putting fixes that they can code themselves into production straight away and they can get frustrated when stymied by something that requires a fix at our end and they can’t code a workaround themselves.

I think it helps to have an understanding of the following things …

• Our Release Schedule.

If you have paid attention to various maintenance releases of our product, you would have noticed that in the past few years the GBC has had close to a monthly maintenance release.  It is not regular in the sense of being the certain date of the month, but in general there will be approximately 11-12 GBC maintenance releases over the course of a calendar year.

For our other products, the schedule is more ad-hoc but you would probably have found that major releases occur every 18 months to 2 years, and that between major releases there may optionally be a minor release or two between major releases. (there was no 3.01, 3.11 but there was a 3.21, 4.01).  For these products, the gap between maintenance releases tends to increase over the lifetime of a release.  A scenario might be that there was a maintenance release two months after GA to resolve issues found by early adopters that weren’t picked up during the EAP, the next maintenance release might be six months later and be driven by a late adopter who has found one or two rare issues.  If there are two maintenance releases close together we might have broken something in resolving an issue and so had to deliver a maintenance release in close proximity to rectify.

• Product Interfaces. 

It helps to have an understanding of how our different products relate to each other and how they interface with one another.

For instance, adding a new widget requires changes to the AUI Tree so involves changes to the compiler (fglcomp, fglform), the runner (fglrun) to put a new type of node in the AUI Tree.  It requires changes to the front-end (GBC) to understand and render the new type of node in the AUI Tree (fortunately with Universal Rendering this only requires changes to one front-end product).  Genero Studio may require changes for the Code Editor, Form Designer, Form compiler.  Any new enhancement or fix requiring a change in the AUI Tree is likely to be scheduled for a release where there is a change in the major or minor version number and all products are delivered.

Adding a new Presentation Style Attribute or Presentation Style Attribute value requires changes to the  front-end (GBC) only, and no changes to fglcomp, fglform, fglrun and the structure of the AUI Tree.  Hence new Presentation Style Attribute or Presentation Style Attribute value can be delivered in a GBC monthly maintenance release.

So for some new enhancements, we may have to put them into major or minor releases so that we can deliver the enhancement in multiple products at the same time.  It is also why there are EAP’s so if there any issues with new functionality across products, they can be found and fixed during the EAP.

• Third Party Products.

We do make use of third party products and libraries and are beholden to their release schedules if we can’t workaround a deficiency in their product.

• Age of Release.

If the release has been out for a while and you are reporting a new issue, ask yourself, why has no one else reported this issue before?  What am I doing that is perhaps unique or unusual.  Could the issue be avoided by being more conventional?  (there was an issue recently reported where the issue has been there since Genero inception, the reporters coding style is very unconventional)

In answering the question “when would you like his fixed by”, in formulating your answer consider the following …

• Is this a production system down or a data integrity issue? As per our service level agreements, there is an obligation to resolve certain issues promptly.  Make sure when filing a support case that you use the priority field and bump the priority up as appropriate.  Make sure the urgency has been communicated to us, and provide as much detail as possible about when you need a resolution.
• What workarounds are available and what is the nature of the workaround?  There is a difference between one developer in your development office being told to use a workaround versus a workaround having to be communicated to 1000 end users scattered around the globe.  For the former, that workaround can be in place longer than the latter.   Make sure the nature of the workaround is documented in the case.
• What product(s) are impacted and where is Four Js at with the maintenance release schedule of that product?
  • If product is GBC, should Four Js put back the next GBC maintenance release a day or two in order to include this new issue, or should we schedule it for inclusion in the next GBC maintenance release the following month, or perhaps the one after? Now that we are settled with the monthly GBC maintenance release, I tend to find most GBC issues can be delivered in next months GBC maintenance release.  That is, we can continue working on the current release without disruption and the fix can be scheduled for inclusion in next month release.
  • If this is a product other than GBC where the maintenance releases are more infrequent, how long can you wait before you need a maintenance release.  What is the date you would need to see a maintenance release by?.

To wrap up with an aside most issues we resolve generate a new QA test so that the issue does not get repeated.  If you discover an issue once you release your product (as opposed to finding an issue during development or QA), ask yourself how could you have found the issue sooner?  Could you have found the issue during our Early Access Program that you did not participate in?  Are you missing a QA test of your own ?  What layers of the Swiss Cheese model lined up for the issue to occur?