Poor Deco Handling

It seems my previous reply got lost with the forum upgrade.

Yes. It was fixed before in 4.0.  Prior to 4.0 it had the same behaviour as above.  After 4.0 it would still do the safety stop even if deco was cleared.

See: https://forums.garmin.com/outdoor-recreation/outdoor-recreation/f/descent-mk1/150119/software-version-4-00-now-available-phased-roll-out-100

** Previously, if NDL was surpassed while below 35 feet, the watch would cancel the safety stop in favor of normal decompression stops. Now, if the deco commitment is cleared prior to ascending to 23 feet (7m), there will still be a safety stop scheduled for 20 feet (6m).

Someone reported something else that reverted in 6.00.  This significantly decreases my confidence in the developers at Garmin.

I'm also concerned that Garmin don't even care about this safety issue but care more about a crappy dive log function on Android phones.

From a liability standpoint, they do care as a company. The issue with this watch is that there are no beta’s, so we have no idea what’s being tested, what has been fixed, etc.

We’re less than 2 weeks away from it being 5 months since the last update. 

I can confirm this has been fixed (again) in 8.00

Yesterday, I (intentionally) went in to deco with only a small liability.  I cleared deco before getting to 5m and the Mk1 gave me a normal 5 minute safety stop.

The bigger issue here is that software updates should not introduce new bugs, or break fixes implemented in previous releases. We keep hearing they are concerned about safety and take their time to test each release, and then there are issues with the release that really should have been caught in testing. This makes me question the testing that Garmin is doing on software updates. Given the glacial pace of software updates, maybe some real-world beta testing could be added to a future update. Well assuming there are any future updates planned for the Descent. I know I have offered on more than one occasion to beta test updates.

As a software developer for 15 years in a previous career I can tell you that testing is the last place you want to find defects. It is far too late in the process and to fix the defect you have to go right back to the coding stage and then redo all the steps again.  Well... that assumes the developer is following best practices.

Note that I’m not suggesting that testing is not necessary but rather it best practices are followed it should be a mere formality.

Now for reintroducing a defect that was previously fixed is exceptionally poor form. Good version control of the source code should all but prevent it from happening. If you happen to work on the same source files as the previous fix, code reviews and unit testing should include verifying all previous fixes so the problem should have been caught very early in the process.

Given the time it takes for Garmin to release updates, they have more than enough time to follow a formal and rigid development process and reverting previously fixed defects should be nigh on impossible. It updates were coming more regularly, this sort of problem would be more accessible as it would suggest they are following a more agile process.

Shearwater, on the other hand, appear to be following an agile process. They get updates out quickly and regularly. While bugs may slip through (uncommon from what I’ve seen) they can be resolved quickly.

In a previous life I was a product manager for both hardware and software products. Only once did I work with a development team that coded this way. Most of the developement teams frequently tried to hide issues, and were more or less rewarded by their management for doing so. So I learned a lot about writing test plans and fully testing the products before we shipped them, as I was the person who had to deal with customers when my products did not work in the field. Of course sales was a bigger problem, promising features we did not have and in some cases could not support without a major development issue.