Question about the quality of the Duet software..

natthapol.v

@oliof @dc42
Thank you very much for both of your responses. I'm just personally doubting about the quality and the test coverage of the more recently software releases. I know that a whole team of devs/testers is needed with enough funds to feed into the development process. I'm not blaming anyone here and also not trying to say who is not competent enough to develop good software.

V3.4 is still under development cycle and a release candidate was just recently released. Release candidate is from my point of view, should be the most recent stable version with zero new features allowed to be introduced to the software cycle. Only intensive testing and bug fixing should be focused at the current state onwards. Maybe you guys have already done enough testing that wasn't documented on Github. I don't mind If the current development process already fits your team workflow. It's really hard for a small team to develop really stable software, It's also hard for one man to keep track bugs that was reported, while also bringing new features to the software at the same time.

Dev hates testers for how annoying and picky they can be.
Testers also hate it when dev made errors on a simple task. No human is perfect even though you thought so.
If the dev has to test his own software, maybe they will find a few bugs here and there, but not much when a 2nd/3rd person looking at it against the written requirements.

Automotive ECUs are fairly flexible as well, with homologation laws and multiple variants of car configuration possible. The same ECU will also go into several car brands and models in its parent group. Some control units from Audi will also land in VW, Porsche, Lamborghini, Bentley, Skoda, etc. Very flexible indeed. They were still able to ensure great software quality in their system as well.

System test are very costly and time consuming to implement and run. But skipping the earlier tests in the V-chain is not gonna help uncover the bug in an isolated environment. At least some tests are better than no tests at all.

I like Duet ecosystem a lot and own genuine board. All the printers that I've built were designed to run Duet from the very start. Never plan to made a switch to Klipper or anything else similar in the near future. I'm glad to hear that further testing are planned in the near future.

oliof

@natthapol-vanasrivilai I am doing my part testing releases on the machines I have, as do many others here. Other people provide documentation fixes or their own code contributions such as the hangprinter people.

You say the project should now focus on improving code quality. That's exactly what the RC stage of a software release cycle is for.

Since you profess experience and knowledge about testing software, and this is an open source project, you could easily contribute to the project by bringing in your expertise. @dc42 has taken time out of his day to address this and provided pointers where he believes unit tests might have helped avoid issues, so you know exactly where to start and prove your claims by doing your part (-:

dc42

@natthapol-vanasrivilai said in Question about the quality of the Duet software..:

Maybe you guys have already done enough testing that wasn't documented on Github.

We don't document testing on Github.

I don't mind If the current development process already fits your team workflow. It's really hard for a small team to develop really stable software, It's also hard for one man to keep track bugs that was reported, while also bringing new features to the software at the same time.

We had planned to migrate the enhancement and issues list to Github Issues prior to the 3.4 release, but are still waiting for one of us to have time to migrate them all, as there's not much point in migrating just some of them. In fact the current issue tracking spreadsheet works quite well for us, although of course it doesn't allow others to track what we are doing.

Dev hates testers for how annoying and picky they can be.

Actually I like picky testers! I'm picky myself.

If the dev has to test his own software, maybe they will find a few bugs here and there, but not much when a 2nd/3rd person looking at it against the written requirements.

I agree, independent V&V is best.

System test are very costly and time consuming to implement and run. But skipping the earlier tests in the V-chain is not gonna help uncover the bug in an isolated environment. At least some tests are better than no tests at all.

Most of the serious bugs we find in RRF are system-level bugs, and only found by testing on a real 3D printer or at least a bench system.

I like Duet ecosystem a lot and own genuine board. All the printers that I've built were designed to run Duet from the very start. Never plan to made a switch to Klipper or anything else similar in the near future. I'm glad to hear that further testing are planned in the near future.

Thanks!

dc42

@zapta said in Question about the quality of the Duet software..:

Are you a Cambridge PhD yourself?

Yes. My PhD thesis went online recently, https://www.repository.cam.ac.uk/handle/1810/331159.

T3P3Tony

@phaedrux said in Question about the quality of the Duet software..:

@alankilian @mikeabuilder
Being active on the forums to help new users is immensely helpful. As is running beta and RC releases when available and providing feedback.

I would like to second this. It is immensely helpful for people to test Beta and RCs on their machines!

zapta

@dc42 said in Question about the quality of the Duet software..:

Yes. My PhD thesis went online recently, https://www.repository.cam.ac.uk/handle/1810/331159.

Very interesting. I expected something related to computing. Maybe the Duet IR sensor has more theoretical depth than we expected.

Getting a PhD and being super productive in development of real life software applications are two different skills. You seems to have both. As your fellow British Ali G. says, Respect!

deckingman

@zapta Just for info, DC mentioned "Oxbridge" graduates. This is peculiar term which might not be apparent to non-native English speakers, but it means graduates of either Oxford or Cambridge universities.

dc42

@zapta said in Question about the quality of the Duet software..:

Getting a PhD and being super productive in development of real life software applications are two different skills. You seems to have both. As your fellow British Ali G. says, Respect!

Thanks! To be honest, the most useful skill that I learned while doing my PhD was now not to do systems engineering.

zapta

@deckingman said in Question about the quality of the Duet software..:

it means graduates of either Oxford or Cambridge universities.

Thanks @deckingman. This explains why when I searched for Oxbridge University I got this

gnydick

@natthapol-vanasrivilai I have to wonder what your background is to be able to comment on software development practices when you mention that it's difficult for one man to keep track of bugs. There are tools for that and it should be trivial for him with his amount of experience.

zapta

@natthapol-v said in Question about the quality of the Duet software..:

From my experience, this has led to several project downfall and abandonware in the Automotive industries.

The automative industry uses primitive and ad-hoc processes compare to the aero-space industry, hence the often recalls

Duet and RRF would be better off adopting the superior quality standards of the aerospace industry since they deal with a similar problem, controlling a reliable movement in a three dimensional space.

Seriously, want more resources invested in Duet/RRF development? Buy more boards.