Patching vs fixing in the Next Version

[DavidJames]

Here is a note that I recently posted in the Case write-up for a bug we discovered in 10.6. The issue here regards how ESRI resolves issues in the software. In this case, a serious problem with the Lookup command forced us to develop a work-around for those users operating in the 10.6 environment. ESRI realized the critical nature of this bug and responded very quickly...they made the necessary changes and are implementing the fix in 10.6.1. As I note below, by failing to patch the flaw in 10.6, there is now a hole in the software that will remain in perpetuity. This 'Fix in the Next Version' causes me a lot of heartburn...as a developer, I do my best to respond to my clients needs for software that is stable and remains as bug free as possible. I would like to think that ESRI would feel the same. When a critical bug is identified, like this Lookup tool issue (and worse -- like deleting your C: drive [bug 000113996]), it is important not to let this problem remain in the software life cycle. Doing so robs the user of their expectations for reasonable stability in the use of the software. ESRI...please embrace a system where critical patches are resolved in the version of the software that they occur!!

While I understand that this case -- and the associated bugs -- are closed, I want to encourage you to address this problem in the version where it occurred, 10.6. the Lookup tool is a critical piece of the tools that we develop using ArcGIS software. By allowing this bug unresolved in 10.6, the work-around that we developed will have to remain in place in perpetuity...we have to at least try to support users in versions going back to 10.3.1. I have to believe that it is in your (ESRI) best interest to provide a patch to existing software with critical flaws like this one and, say, the bug 000113996. Failing to do so leaves a hole in the software that will last for years...10.2 will not retire for another year.

[MichaelVolz]

I would also think this is important if your GIS system is tied into other enterprise systems that would need to be upgraded as well if the issue if not fixed in the current version.  As such, a bug in GIS software might result in an organization needing to upgrade other systems besides GIS.

[MarcoBoeringa]

Can't agree more. This unfortunately has been a long standing issue, with ESRI's focus always being to much on new development, and not adequately patching up existing installs. With the development efforts for Pro probably drawing heavily on the developers pool at ESRI, this seems to have gotten even a little worse, since now only rarely hotfixes are released, where maybe a few years ago, there were still regular hotfixes downloadable from the ESRI support website.

I have always thought ESRI should at least double its efforts in bugfixing to really get to grips with the inevitable issues popping up with new development. There is simply to much time lost by users with broken software.

I also think there should really be a better priority for bugfixes:

- Regressions in software, that is, existing functionality of a previous version getting broken in a new version, should always result in a hotfix being released A.S.A.P. Regressions directly and immediately affect the usability of the software, and if no workaround is available, can lead to a total disruption of existing workflows and thus have heavy consequences for the existing user base after an upgrade, and in addition may lead to the need to "downgrade" to the previous version as well as not being able to upgrade to a new version to take advantage of new functionality.

- Bugs in new functionality being introduced in a new version, although a nuisance, are of lesser priority, as no one yet depends on this. Even though problematic and a possible disappointment to those wanting to use the promised new functionality, these type of bugs generally do not lead to serious disruption of existing user workflows.

I have seen few signs that ESRI uses such prioritization, other then ESRI calling upon its user base to request hotfixes in case their workflows are heavily affected by some bug, which I find a to passive attitude to the problem. If a regression is identified, ESRI should to get to work without asking users to send in requests to get it prioritized.

[Orca654]

Sounds horriable about this Bug 000113996: BUG-000113996: Running tools multiple times that use distributed pr.. 

[ThomasColson]

Sounds like a security issue: if content on the C drive get's deleted, and the OS rebooted, some critical protection file, now gone, allows hackers access to something. What about those laptops at the remote field station/fire fighters now on a 3 month detail that have 10.6? Wonder if there's a CVE #?

The support life cycle of Arc and Pro, and the availability of critical patches as opposed to running around upgrading 10's or hundreds of computers RIGHT NOW when we just did it last month is weighing heavily on our decision, yet to be made, about moving to Pro. I've been down the hotfix request road before. You get the Spanish Inquisition about why it's needed "Ummmm......it deletes files off the C: Drive".  With a new version of Pro seeming to come out every 6-8-months-ish, I'm already having a hard time getting IT's attention.  It takes us 6 months to get our hands on each machine to do an Arc Upgrade.  I get that some, if not most, bugs and enhancements get punted to the next version. 

Thankfully, I'm not moving to 10.6, as a matter of principal, and one most IT folks subscribe to, NEVER install the .0 version! I add to that by skipping a version: 10.1, 10.3.1, 10.5.1.....and that's an IT rule. 18 months is the minimum upgrade cycle they can support, looking at their project list for the next 3 years, that's going to turn into 24-30 months, which puts me in the very uncomfortable position of having a production deployment in mature or extended support. When you throw ArcGIS Pro Publish Services To ArcGIS Server  into the mix, and now have to patch and upgrade significantly more components, the workload gets tougher, and often, not sustainable. Imagine a "delete stuff from the OS" issue in Server or Portal, that "is fixed in the next version". Wut?!?! We just spent 12 months, 40 hours on the phone with Premium Support, and had to pay IT overtime just to get this version running! I had one in PTL where just clicking a button (in PTLADMIN) crashed the OS. Due to the security issue that presented, we just removed the functionality that we desperately needed. Security trumps functionality these days. Sorry folks, we're not supporting AD groups in PTL. 

As for " existing functionality of a previous version getting broken in a new version", we can definitely apply that to Pro, but replace "broken" with "missing" and "Pro is replacing desktop", the Support Lifecycle Calendar for Arc thumb tacked behind your desk, and users whom you support not quite accepting your explanation of "Arc Catalog isn't gone, it's just different". Totally understand that all sort of previously unheard of functionality takes a while to get right, but I'd much rather see the tools I need to do my job work, and work well, before I start exploring 3D forest inventories and "Projects". 

There's some kind of Urban Legend that all GIS'ers install the latest Pro or Arc Map the day it comes out, and the support life cycle dates support that. It took me a year just to get Pro to the point where I could expand acceptance testing beyond my own workstations. I do not, as a matter of principal, go to IT and have them install a version, that, come to find out, deletes stuff off the C drive. That would be the last ESRI software ever approved on the network. We've all had the TS call where the solution is "The next version fixes it", but, alas, IT is not installing the next version. This gets more complicated as we move into cloud based deployments and start to move workstations closer to the data with RDI and Citrix, and there are greater dependencies on versions and significantly longer lead times in certifying a version for deployment in a cloud solution that support 1000 users. One simply does not install 10.6 or 2.2 in a mass deployment without months of testing. If someone went through that amount of blood sweat and tears to deploy version x.x, as I suspect the OP did, expecting a hot fix for a critical issue is legit. However, in a nod to TS, I certainly wouldn't be (and don't) demanding hot fixes for every minor bug, such as "icons get deleted when you search for Jerry Garcia in Locator" (because you're looking for the Easter Egg you know exists in Pro......). 

Perfect world: Major release of Pro every 2 years, on January 1. Service packs every 6 months. Hot fixes for critical issues for the previous 2 versions which don't need to be begged for. I say that tongue in cheek, because, if I have to wait 2 years for the ArcGIS Pro Publish Services To ArcGIS Server   bug to be fixed......

[MattStull]

Great point!  and a very important one to!

[BrianGelder1]

That bug was a pretty fun one! I discovered it and lost a few weeks, some data, and had to rebuild a couple computers. And it's not just data on the C drive that's at risk, it's whatever drives have workspaces you're accessing. I've been stuck on 10.3.1 due to a bug in 10.4.0 that didn't get fixed until 10.5.1 and was hoping I could finally upgrade and discovered this while checking things out. It looks like I'll have to go straight to ArcGIS Pro or stick with 10.3.1 with the tool I'm working on. I understand the 'wait until the .1 release' logic, but if everyone does that these bugs don't get discovered until the .1 release. Someone's got to test it (but it should be ESRI...)

[JohnJones]

Just to clarify, there is not a Jerry Garcia Easter Egg in Pro.

[MarcoBoeringa]

I think there are enough "Easter Eggs" in Pro without Jerry Garcia involved 😉

[ThomasColson]

The solution "Use ArcGIS Desktop 10.3.1." seems to imply that this is also the case with 10.4 and 10.5. Is that in fact true?

[BrianGelder1]

I'm not sure, I think the bug was brought in with the Multicore processing stuff, but ESRI doesn't tell you much on why these things happen. I couldn't use 10.4.X or 10.5.0 due to BUG-000095793, which corrupts Zonal Statistics Maximum calculations. I also found a few other things goofed up in 10.5.1, like Int and Abs calculations when used inside other SA tools.

So, for me, it's 10.3.1 or 10.6.1 (fingers crossed) or Pro.