When will garmin release a stable software version for Epix Pro with no problems at all for all advertised functions? Finally that's what i have paid for.

I agree  I think it's a little bit of everything. The software department is pressured by the marketing department to release a stable version. This people usually have a different idea of a stable version. In other words time is always s critical resource and the number one reason why any kind of product is released prematurity. Software is no exception. 

An autopilot of a plane or an ECG is tested for years before a hospital buys it for a significantly higher price then it would cost with a shorter and less intense testing period. Hence, the product price is a limiter too. People always complain but are not willing to pay for their expected quality standards. I rather pay 1k for a product that gets incrementally optimized during it's support cycle instead of paying 10k for aerror free thoroughly tested watch.

Then we have the limited number of developers. Usually, the number of developers is never enough in relation to the work to do. I guess that's the case with every kind of project. Maybe Garmin should employee more developers. Who knows. I feel they release at an acceptable rate. There were a lot of updates recently.

I personally think they were pushing to the market to early. If it was bad luck or stubborn marketing strategies we don't know. I agree that companies at times push it too far with releasing software that is known to have an inappropriate number of bugs. I mean they will fix it. But it's not a nice experience for the consumer. I'm with you in this point. 

But I think the request for Garmin or any other software company to deliver a bug free software is totally unrealistic. I understand the frustration. But unrealistically high expectations only make the pain grow.

This all happens because people don't value the work that's behind software engineering I wish it would be obvious to everyone that software engineering is technically equal to aircraft engineering. To make s product assurance for the consumer market w have to expect that the manufacturer cuts trying period. Like in evolution, less time means more bugs. And even the airplane that is so structure tested for s long period of time had bugs and later crashes.

I'm not defending Garmin. I'm defending software engineering as I feel the problems were are talking about are very common and are only an issue because people think that because the UI is simple the application or software behind it is simple too. Building a plane, everybody would consent that it is a complex project for a complex product although they don't have a clue about aviation. But when it comes to software then this kind of understanding is clearly missing. That's my basic point.

I also have many more electronic devices that are super stable, and I use those regularly in the kitchen, living room etc.

This watch is a very advanced and miniturized device that is characterized by a huge amount of functions, while having a long battery life.

Sure, i also experience some issues with my watch, and I hope that these will be resolved soon. Nonetheless, I accept that I can only support resolution of these issues by constructive and supportive feedback.

And despite the issues, the watch is still a great product that supports me while doing workouts and trainings. Furtermore, this manufacturer does not for e me to be locked in into an ecosystem where I have to by their products to have a funtional watch. I greatly appreciate to be able to upload my own maps for example.

Yeah, I got it. My biggest complain is about regressions more than bugs. Regressions are subtle bugs because they impact the trust you have in the device. When a feature stops working because of a bug, it makes you wonder if a critical function you rely on could be compromised by an unforeseen problem/update in the future. In my case, critical function is the alarm to wake up in the morning. As a deaf person, I need the vibration as I can't hear an alarm and it happened 2 times that it didn't work. So yes, I can accept it hasn't the stability of my cochlear implant but I have some implicit expectations from the watch. As you may know, implicit expectations are the assumed ones that, if not met, create the most impactful distrust ever possible. To make an example, the implicit expectation of a flight is that you're not going to die in a crash.

You may argue that if I have such an implicit expectation from the watch, I should buy a different kind of device but this is a worser reasoning for this specific case: if I can't trust Garmin for an alarm then what is this device made for?

This is the reason why I'm advocating for better software development best practices: there are some things that should stay stable: anyone has its own different implicit expectation.. Some of them are obviously unrealistic but for all the others, we deserve to trust the watch and it falls short too often.

Hi John, totally with you. This is the reason I'm still using the watch and love it anyway. That said, Garmin can improve a lot in improving the stability of their software. This is what I'm advocating for: a better management of software cycle releases especially for those functionalities that are easily debuggable.

Again, you have some great points. Maybe it's that we always expect a single device to do it all. And maybe it's also the manufacturer that kind of implies to satisfy that expectation. As you put it maybe it's just smart to do it like how the avionic is doing it: not to rely on a single device that does it all and to implement redundancies. In your case a second standalone alarm clock :D

I'm kidding (although there is some philosophical truth about it). I'm in full consent that if I sell a do-it-all device that it should at least do it all reliable (good is another question). I also agree that if Iin a complex system something is broken the whole system is kind of compromised and potentially broken or brittle at least. I mean you won't use that Garmin standard to send people to the moon. We can only hope that the production standards are good enough to guard against that kind of bugs by implementing proper unit tests (especially thinking about test coverage at this point). 

Also I think the software development practices are not the problem. The engineers are usually dedicated and want to do the best that is possible to create something they are proud of. They are usually open to new technologies and told. It's always the marketing teams and the consultants and the management that throw the sticks into the wheels. They define the project deadlines and requirements. And they define when the product is ready for the launch (in terms of retirement fulfillment). These people always spoil good product development. I understand what they are doing and that they are doing crucial work. Sorry I'm case I offend somebody ;) But from an engineering point of view they are ruining it all. The interests are not the same. Therr is some intersection but the main motivations didn't align well. Marketing is happy and evaluated as efficient when the complete product is developed and released in the shortest time frame possible. Engeneers are good when their developed product is robust and smart which usually takes time (evolution). That's when working in major projects starts to become frustrating - for every one involved.

Do you know how Apple is doing? I mean they are a much bigger and wealthier company that would have more available human resources. Are they struggling the same? I personally don't know any Apple watch user. But I'm general I associate Apple with extraordinary (monetary) efforts to create reliable products.

When will people stop complaining and just sell the watch and get the cheap one (that always works sooo much better) they always mention, but never specify, and enjoy life and their outdoor activities?

In case of Garmin, I'm prone to identify the issue in the tech stack more than in the MKTG team. I agree on your statement about engineers desiring to create the best product on earth but time plays a crucial role in products evolution. If you think historically about the most advanced Garmin outdoor watch, the Fenix, it went out in 2012. I can imagine that Garmin, entering a new market, had to balance investments with failure risks and they hadn't enough resources to create a new platform from the scratch considering their failure in the automotive GPS market where they were cannibalized by Tom Tom (at least in Europe).

So I suppose they got all the existing tech stack (pretty old dating back to the 90's) and built on top of it. After all, it was working very well with battery powered devices, it was powerful enough to cover all the use cases of the watch and it was very advanced in GPS tracking. To be honest is more than a supposition as Garmin is using a realtime operating system written in C/C++ (more on this in this podcast cppcast.com/.../)

It was a very good and successful business decision but after a few years, some of the limits in the stack started to materialize as it happened to Apple itself (after years of trying to improve the classic MacOS). In fact, the Garmin Os has the following limits:

– no memory protection
– no processes
– no kernel protection or kernel/user space
– everything is a single process with threads
– everything is C and C++
– basically any programming error can hang or crash the watch

Engineers made a truly amazing work in improving it for all these years but I think some of the regressions we see today are a consequence of using a pretty dated and spaghetti coded platform. This suspect arise when some regressions appear even without explicit changes to the relevant code (for example the latest regression in power mode).
So today, Eng has to:

- Cope with MKTG requests in a very competitive landscape (where Apple is leading the evolution having a really good platform)
- Cope with an old platform very difficult to maintain

In addition, other choices exacerbated some of these issues. In the aforementioned interview, the Eng said that the choice of Monkey C was due to the fear of Oracle suing Garmin for Java copyright infringement. At that time, they could have gone with Nodejs or other stacks. Instead they used an internal developed interpreted language that has 0 traction on the market and no one knows. This means they had to spent a lot of time to develop all the libraries and to maintain them. This makes also 3rd party application development much harder than it should be...

Regarding my thoughts on Apple you can find a snap here (the message above the linked one forums.garmin.com/.../1791363

Yeah the best architecture will age. Legacy code was the downfall of every company I have worked for. The time dramatically shifted from the implementation of new features to maintaining old features. Some could save their business by focusing on encapsulating their business algorithm like optimization algorithms for example in the g field of logistics. They had to do this because their applications  had become unmaintainable over time.

Every bad design decision, most are related to tech stack choices, will turn against you at some point. It's like Murphy's law. Add to that the lack of programming skills of some developers. Because the management only cares about results and is pushing too hard, all that messy quick-and-dirty "we will fix that later" code starts to creep in and to accumulate. It will linger around forever. People leave the company and that monster that nobody wants to touch grows and grows. I really hate to work on such code. Everybody is frustrated. The team that created that messy is long time gone. Everybody wants to start from scratch using latest technologies to create something better and modern based on the mistakes that have been made.  But management says no. No time. Usually the companies don't have enough resources to develop a product from scratch while still maintaining their current products that actually bring in the money.

This is likely a big part of the reason that Garmin has a difficult time to implement fixes fast and l without breaking code. 

However, it's always difficult to pick the right technologies when you start a project. I can't blame Garmin for their bad decisions. Lots of promising technologies disappear. And some you picked because they were open source are now licensed (like the dreadful Oracle did with Java). Evolution here ist very fast and unpredictable.

And in terms of the architecture and extensibility of the Garmin source code I believe that old applications, maybe older than 5-8 years) are really obsolete because of the fast evolving technologies, architectures and the way software is developed today. Modern architectures are usually service oriented like micro services. Loosely coupled components. You can easily hook in components independent of their tech stack or languages. 

Also using a proprietory OS is always a bad idea. I would rather pay the license fees, at least for the kennel. You can never maintain an OS as a side project. Imagine the effort they put into their OS. Like they could never envision the success of their watches. It really was a niche when the Fenix series started.

I guess Garmin's next big step will be a new platform with a better interface for 3rd party plugins. This way the platform gets richer and more attractive. And they will move to 3rd party OS I will bet. A modern kennel architecture will solve the threading and process isolation problem. The result would be a faster and stable device with significantly less crashes. My Edge 840 is 4 month old and has about 4 crashes of which 2 froze the device and required a hard reset. I think with today's hardware you can easily run an Android kernel on the watches. It would be so much easier to add smart features and other apps, like of certain music providers for example, if they only have to provide a GUI instead of developing a complete new application for the Garmin platform. They could directly use the mobile Android version. 

You are absolutely right. Beneath the bling is a really antiquated technology. And I'm pretty sure they are already about to fix that . The competition got really strong. All the competition entered the market with a modern platform that I expect to scale fast better then Garmin's platform can ever do. They will lose market shares otherwise. Nobody cares about their superior algorithms to calculate the metrics if their devices are not stable.

Those platform limitations you mentioned and the security risks they imply are likely a reason for the reluctancy of Garmin to add real smart features.

Seriously, you gave me chills when making me think of how their legacy code base looks like :D

The links you provided are very interesting too. Thank you very much!

I don't blame Garmin for their choices and some of them were right back in the days. To be honest, mine is just a reconstruction so it can be utterly wrong. Regarding the OS, I agree with you. I hope they choose something like FreeRTOS to avoid maintaining it in the first place.

Regarding the 3rd party application I like the approach of Amazfit and ZeppOS!