There’s this concept that I learned back in the 80’s when updating or upgrading systems. It’s called Beta Testing. It’s a process where basically the program, as we used to call them, lives in a sandbox and we would try to break the program anyway possible by doing normal and non-normal things and then we would give exception reports to the programming team. We’d only release the program into public usage after we couldn’t figure out how to create any more exceptions.
Maybe LingQ could do something like this when “fixing” code or “upgrading” functionality. I’m a bit burned out figuring out work arounds when things stop working.
When I was on a team merging two fortune 10 companies in the 90’s the company who was taking over the other one used to joke that the company that became defunct used the ready, shoot, aim method of completing projects opposed to the more acceptable ready, aim, shoot method.
This is a long way of saying please get your functionality in order LingQ. It’s very tiresome working out a study method and then having it screwed up by functionality change that basically breaks the site.
The only time they introduce beta testing is when there is a change of version, for instance when the site moved from version 4 to 5. When it comes to other functionalities, they have a terrible habit of releasing them before they are fully ready and us users are left to do the beta testing and bug reporting.
It’s been like this for years and I really cannot see them doing things differently.
To avoid pulling my hair out on a regular basis, i have resorted to using Lingq strictly for reading (while making sure lessons are not exceedingly long or the site lags like crazy). I now do the listening outside of Lingq as the constant bugs with YouTube imports and Whisper were driving me bananas.
The 90s are long over and more modern approaches have become best practice.
If we look at Game Development (which is a gives us a lot of big software development projects to observe as a sample), you will recognize that games are almost never finished or even in a working state when they are released. Think about it this way: If even multi million dollar companies can not release software in good state, how is a small team like lingq supposed to ?
It is simply a mathematical problem. Lets say link has 10 devs and 10.000 users. That would mean, that one hour after the release of a new version, users have invested as much time in the software, as it would take the team 125 work days to archive the same time in testing.
That’s not how it works. The idea in rapid development is to release a minimum viable product as soon as possible. Then features are added and changes are made according to user feedback. Releases are scheduled with a selection of hoped for changes. Not all will make it and some may be shunted to a later release. However, that does not mean no regression testing. It doesn’t mean the users are the beta testers. There are many approaches, but a developer is responsible for testing their changes before submitting it. That may mean writing unit tests which are run to validate existing functions. There should then be a process of validating the changes in the product. Perhaps a candidate release is created, and it goes through automated regression tests, perhaps with some manual tests. It might even be released to users who have agreed to act as beta testers. Once it is approved, it is released.
There are ways to reduce the likelihood of one change breaking other features. Dependency injection and Software As A Service is on method. In short, you decouple features as much as possible. The opposite is spaghetti code, make a change to A, and B and C break. Fix B and C and D breaks.
My experience is that a lot of things break on a regular basis indicating a lack of regression tesring.
Under the assumption that all 10.000 users use the software immediately after the update, do throughout testing and give feedback, the latter assuming they consider it to make any difference. And even if all of this would be true, does it justify that we get misused as unpaid testers? I don’ think so.
The question is whether they could’t or simply don’t feel the need to. At some point software developers realized that people will be happy with anything and they don’t need to do well as long as they feed their customers some nice additions here and there. And the customers got so used to it that they simple assume that it has to be that way.
And if you consider ‘performing bad at your job’ a modern approach, I want back the good old days. And the games from that time, they were better.
Yeah idk what ever they did recently has really made importing lessons a huge pain which was one of the best things about this site. I think they really could benefit from testing more as well.
Lingq seems to be doing the opposite of that.
Lingq is like a carmaker that adds every possible feature to its vehicle, without fixing longstanding issues with the engine and drive train. Heated seats are nice, but I’d be happier if the engine would start reliably. It would be even better if the wheels would turn.