Just take a look at the wealth of errors that fills the startup logs even when things are going normally, does that look like something a company that prioritizes fixing bugs would produce…?
Riding on Zwift makes me feel like a living bug database pretty much every time, any ideas what I should do differently to fix that?
I realise that you probably asked this rhetorically, but I’ve been giving it a bit of thought. I’ve been shocked at how often Zwift manage to introduce bugs (quite serious ones at times) and how difficult it is to get them to fix it. I’ve been trying to think what we can actually do to sort that.
There’s clearly problems within Zwift both culturally (if they’re happy with this situation) and technically (if the developers are introducing this many bugs, there likely isn’t enough testing). However we don’t have control over either of these things, and really can’t influence them directly. The only thing that we interface with is the support team, via this bug forum.
And that brings me to my suggestion, I think the best thing we can do is to actually agitate for them to get rid of the bug forum. Bear with me, bear with me!
The problem with having a “bugs” forum is:
What really needs to happen is for ALL bug reports to be a conversation direct between the user and Zwift support, free of interference from other users. And you know, guess what, if they start to struggle under the strain of so many bug reports - well maybe that will indicate to them to fix the actual root cause and stop introducing so many bugs, and fix the existing ones. There’s simply no pressure on developers to do so while nobody in Zwift is feeling the pain - they have just given us an area to shout but there’s no “cost” to them from running the forum, there’s no one forced to respond to bug reports, and so they’re free to continue introducing bugs and ignoring user complaints because they literally don’t feel the pain.
Even companies that operate at massive scale like Microsoft and Amazon and Apple still have a real support service with email and phone support and tickets, and don’t push you away on a forum with no direct interaction. Its just not acceptable, and we are being fobbed off. We’ll never get bugs fixed, and never change the culture within Zwift so long as we continue to allow them to disassociate themselves from the pain of a bad release. If they introduce a major bug, their support team should feel it, groan under the weight of customer contacts, and be a force agitating within the company for better quality control and process in development, testing and release of product updates.
I know this has been a long post, and doubtless slightly ranty and opinionated, but it best expresses what I think is going wrong currently. I’d be interested to hear your (and others) thoughts.
Superb post. Welcome to my world.
I did share my perspective on this in one of these bug threads. For context: I worked on (and managed) engineering teams for many different large scale consumer products for over 20 years at one of those big tech companies (for which people tend to assume all teams have infinite resources). I also spend a lot of time with people who work in the other big tech firms since people do move around a bunch, so that’s where my perspective comes from - others might have different perspectives.
It was always really frustrating to hear people talk about how a company worth $‘x’ billion could possibly not fix ‘y’ pet peeve of theirs, when in reality there are so many pressures on a dev team’s limited resources that you kinda have to see it to believe it.
For example, I used to sift through new bugs every single day (some days we would get 100s of new bugs (some from UI automation, some from crash reports, from external partners, some from end users, some from internal testing, and also from internal execs who had a friend who noticed something off and all of a sudden it was a big problem 
etc. - often changes from another team, or a platform change would siderail things), and we’d only really have time to scan some of the titles) to help decide which were the most-high priority to fix etc. Our teams were never resourced to fix (or even reproduce) all bugs, and we didn’t actually have dedicated support staff for many of these products even though they were consumer focused products (many teams in these larger companies use a centralized support model not dedicated to any single product). Sometimes we would dedicate milestones completely to quality which would be trying to plow through bugs, refactor the code to be more sustainable, investments that would result in a more stable base etc… (after a big release etc.), but even then, the number of bugs would still go up over time if we tried to fix every glitch.
Zwift is different because the company focuses on one core product (two if you now include the Zwift hub). But for a single product it does have a fairly big support matrix of platforms, and devices, which means they often have to make compromises etc to work across all systems in a similar manner etc. You have no doubt seen how regressions have made their way into the product even in areas that haven’t had any major changes. Likely those regressions were caused by a bug fix in those areas. Bug fixes can also introduce more bugs for example.
The reality is, it is easy to sit on the outside and point to a lot of visual bugs and assume the devs don’t care about the product, or that the culture is not the right one. What would be a lot harder would be for you to sit down with the exact resources Zwift has available, to look at the backlog, and to look at the highest priority bugs in their queue, and prioritize how much effort goes into the hundreds of crashes vs. performance fixes, vs. accessibility changes, vs. visual glitches, vs. localization issues, vs. regressions from recent features etc, and then see how much resourcing you have left to add new features to the product.
Usually teams have to make some form of tradeoff on how much of their time they should work on new features, vs. basics/infrastructure, vs. legacy bugs. What you’re essentially saying they are putting too much time into new features or basics/infrastructure, and should put more of their effort on visual bugs. That might be true, but it’s hard to know without seeing the full picture of what they are working on.
Thanks for taking the time to reply in such depth Aaron, I appreciate it, and great to see insight from someone that actually works in this area. As I’ve admitted, I’m not a developer so I am definitely looking in from the outside. That said, I think it boils down to two three issues for me that you mention:
That’s a problem of the company’s making. If they choose to throw tens of millions into marketing and customer acquisition (as Zwift do, they run TV ads and advertise far more heavily than any other product in this space, by what seems like a factor of ten) and not resource their development team, that’s a choice. Its not shade on the individual developers, but it is shade on the management. Choosing to underfund a development team is a choice, not a necessity.
This is the second point I’m making. I use many, many products and NONE of them have anywhere near the number of bugs (“regressions”) introduced as Zwift does. I use hundreds of apps on my phone, tablet, PC, and I’ve played computer games too and not one of them has had the continuous new bugs on new releases that Zwift does. It is atypical in my experience, and indicates something is wrong, to me and many others.
I find this hard to accept that anyone even disputes. They ignore bugs that have been outstanding for years, and instead introduce things that no-one asked for and can hardly even be described as “features” - a new font that was almost universally derided and they had to partially rollback/redo because of all the problems it caused, dinosaur costumes and lederhosen - this is all frippery and development time that could have been spent on fixing bugs. Again, not an individual developer’s fault but you can understand why someone who is looking at the same bugs days in day out gets frustrated when they are not fixed (or even seemingly passed to developers to fix) and the people involved tell the developers to work on stuff like this instead.
Triage gets more difficult the more bugs there are, and obviously there is something very wrong with both the code base and the QA processes when the software breaks in strange and unexpected places with almost every release (endless challenge unlocks being the flavour of this month), and this kind of firefighting tends to steal attention from both process improvement and less critical issues. As a point of reference, I like to bring up this one:
All the same, most of the time when I try to resolve Microsoft or Apple issues, a web search typically brings up a number of hits from each company’s official support forums. Especially on the MS one, the answers are mostly useless (have you tried turning it off and on again). There may be a real support path available as well, but my expectations are too low to bother dealing with that as long as the issues are non-critical. Realistically speaking and as an industry-wide phenomenon, I’d say your lifetime customer value needs 2–3 more digits to be able to expect support where someone is actually interested in resolving your issue all the way through.
Is this issue already known to Zwift development team please @James_Zwift @DavidP ? Any plans to fix?
Oh, I think Zwift is “only” at -1 (WTRL is definitely at -2 though). And yes, it seems abundantly clear that that the whole game should have been rewritten with a more stable foundation at least 2–3 years ago but no signs of that happening…
To bring this back full circle to the actual topic, I’d guess that there is some underlying fundamental design choice that makes it very difficult to do sensible things having to do with the road ahead around intersections. The nearby riders list is another one that goes haywire in addition to the workout portals and the road profile.