Not Designed Right

Hi Michael,

Thank you for sharing your feedback with us. We respect your analysis and would like to share the steps we are actively taking on our side to address these issues and improve the stability of plugin.

In the last couple of releases, we have refactored some key logic and as a result of which some of our users had to face issues with their quizzes. We do several rounds of testing both manual and automated before releasing any code to production. However, sometimes certain bugs manage to escape our testing procedures and end up in production on some specific environments. To mitigate this, we have expanded our test environments and continue to do so in order to cover as many scenarios as possible.

We are also upgrading our database architecture and improving the database normalization while reducing the serialized data that currently exists. One of the key features of QSM 8 will be an upgraded and database architecture that is in accordance with normalization rules.

We are also refactoring the big functions and breaking them down to smaller independent modules that are reusable and flexible for future enhancements.

We understand and acknowledge the issues that were faced by several users of last couple of releases and are trying hard to learn from these incidents and be more cautious while still pursuing our goal to deliver a stable and more powerful plugin in the near future.

Once again thank you for sharing your feedback. If you have any more suggestions for us, please let us know.

I’m sorry, but this is not going to be as easy as you expect.

I’m now solving problems directly related to this problem. And its clear, by your answer you do not understand the extent of the problem.

Currently, for instance. The duplicate quiz feature has a MASSIVE issue, and its directly related to the lack of any proper development on the database. Not only that, but the methods you use to store data is greatly lacking and unable to accomplish what you set out to be.

Specifically, you often use duplicate, and unnecessary references in the database that creates problems when you start modifying the data. The usage of “Results” table makes no sense, and you have ID’s strewn through out serialized data that are never updated. You are also using many ID’s for the same thing (Like adding a UID to tables, for no apparent reason). Which results in problems that are hard to find, and harder to fix as they result in inconsistencies depending on how you join the data, or what field ID you use.

So right now, we are currently trying to unravel the latest mess. Which happens when you duplicate a quiz, and then answers of that quiz are later edited. This problem causing the answers to change in multiple place when users modify the quizes, and results. And depending on what ID you use, for what record, you get different results. Even different IDs (like Quiz IDs)

Other problems are plentiful. For instance, the results table is pretty ridiculous. Why are you even referencing the quiz_id in it? The quiz_id can be found by accessing the question the answer resolves to. By adding the quiz_id to ALL of the questions, you create a huge issue with corruption of data if ANYONE uses the quiz duplicate button.

“Results” should not even be a table. We don’t store Results, we store answers. We calculate results from the answers. The results are calculated from that, and should not be part of the data design. The existance of a results table is a blatant infraction of normalization that is easy for a trained data engineer to recognize. If you want to store results, such as averages, you should either calculate them on the fly. Or use a cache layer to save, and retrieve these values in a way that allows for re-calculation as the answers expire.

I can continue, with MANY, many more examples of how QSM data is a mess. Its absolutely out of control, and were struggling to even solve these issues as the data layer is so contorted it doesn’t even allow us a very good way to explain the issues we face.

I’m not sure how you will resolve this data layer issue. There will need to be a good thousand hours to do so. And doing so will break all, and any code you have. Including the extensions, and addons you and your third party developers have created.

And since the problem is so extensive, any routines you build that transform the data layer will cause other problems for your users when they upgrade.

Ultimately, you got a mess on your hands. And its going to take a ridiculous amount of work to solve it. I wish you luck on this, but we as your customers, are now suffering because of these bad choices. And were in a situation with very few easy solutions, we now face excessive costs trying to resolve the issues we face with it. Our custom code has also been using this broken data, and thus the problem expands till it becomes insane.

I wasn’t responsible for suggesting this code. And to be honest, I may have not caught it had I been responsible for that decision as I typically don’t check the way these plugins are built. But given the extent of the problem, I’m very worried for Us and your other customers and can’t possibly recommend this. In fact, I can only hope to discourage people from investing in any solution that utilizes this code. And I’m not sure you, as the plugin developer, can afford to fix these very expansive mistakes.

I’m sorry for this news. And I wish you the best of luck. But the quality control you have, needs to be better. It appears that some of your solution providers have also made things much worse by going back to the problem for the solution. Thus, we now have about a hundred problems with the table structure. If you didn’t have so many plugins, and such a large user base, I would suggest a complete re-write. But that will abandon any of your current users to their problems, and make transitioning hard for anyone who uses your system for extensive testing (like we do).

• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.
• This reply was modified 2 years, 9 months ago by Michael.

Just to expand on this issue:
https://condor.depaul.edu/gandrus/240IT/accesspages/normalization3.htm

Also, please keep in mind. That these failures in design cost between 10-100 times what they it takes to create them to fix.

This means, that proper and tight control over your database is about to cost your company (and us) about 10-100 times what it would of cost for you to design things right. And due to the shear number of problems, I expect this will compound the project till the problem is no longer affordable to resolve.

Thus, I suggest you put a warning on your plugin not to use in systems that need to deploy hundreds of quizes (like we did).