The Future of PC-DMIS BUGS

I get where you are coming from but it would be too time consuming to run the software through every single scenario that their customers do. If they did, it would be 5 years between releases and the rollout of new features we ask for would take forever. Who better to help test the software then the customers who put the software through its paces every day. We, as programmers, do more with the program in one day than they could do in 2 years because there are way more of us than their are of them.

I get the frustration, trust me I do, but in the end you are helping make your job easier.

That being said... I wouldn't say no to a nice Hexagon polo shirt...

I get where you are coming from but it would be too time consuming to run the software through every single scenario that their customers do. If they did, it would be 5 years between releases and the rollout of new features we ask for would take forever. Who better to help test the software then the customers who put the software through its paces every day. We, as programmers, do more with the program in one day than they could do in 2 years because there are way more of us than their are of them.

I get the frustration, trust me I do, but in the end you are helping make your job easier.

That being said... I wouldn't say no to a nice Hexagon polo shirt...

I don't know how things are run at your place, but here, decisions ($$$) based on what the CMM reports say are made every day which calls for a software that is tested to the teeth to not spit out erroneous results. If you are a software developer and cannot understand the importance of this, you should really consider a job change.

vpt.se We rely on what the CMM report says too but we also realize that no software is 100% bulletproof and certain dimensions, regardless what the CMM says, will be dissected and verified to the best of our abilities either with the CMM or with manual checks.

Again, I understand the frustration because we run into it here too, but realize the size of the team that would be required to run the software through every possible situation that it will encounter out in the field. I think you would get an update every few years and the cost would triple or more because of the manpower that would be required. Even after all that, there might still be some small bugs that would have to be worked through.

I'm not trying to defend Hexagon or bash them, I'm just looking at it from a logical standpoint realizing the size and complexity of the software. They have done a good job so far and I'm sure the company I work for doesn't mind me spending a little time figuring some workarounds to some of these bugs and they have no problem with me sending crash reports and communicating with people, both on here and at Hexagon, to figure out some of these problems. I equate it to the machinists making a setup part out of cheaper material before making the part out of good expensive material. Not an exact equal but it's the best I can come up with at the moment.

Of course - but my "beef" is that there are too many issues and the issues related to calculation done in the software must be priority one - which it seems it is not. As an example, autofeature filtering issues (the filtering isn't done at all), the UPR value maxes out at 1000 which is bonkers, etc.

In the end, you will have programs that were made when it was working, program that contains workarounds when it didn't work etc, etc. That stuff needs to be more thoroughly tested prior to release. And if it were discovered prior to release but released anyway, it needs to filed as "known issues" in the readme - but there aren't any, ergo, they didn't test it/find it/chose to not say anything?