Quality of PowerTools (was: Del button .. no function)
jv16 wrote...you cannot modify or even see the list.
Thank you.
For clarity sake, I guess the files in the Ignore sub-directory are collectively referred to as the Ignore List (version 1.3). Specifically, the file in that directory I was referring to was "Just to be safe.dat" that contained the following instructions:
//These items are here only to be on the safe side. If
//you carefully check each entry before you remove it
//you can delete this file.
Admin //It's not a good idea to mess with Administartor options.
Component
Firewall
Install
Register
...etc.
So, I was actually looking for a way to remove, not add, items. If you care to, please see my previous post about considering it as an advanced feature for the future.
Thanks again, and looking forward to your next release.
jv16 wroteWhere I am standing there are bugs in every single real software product. Therefore if bugs are a process failure, every single computer software company in the World seem to have this failure or failures in their development process.
Sure. But every defect has a root cause, and the professional developer studies the defect until he identifies its root cause. Once you've understood the root cause, you alter your approach to address that weakness, which helps you avoid repeating the class of mistakes it causes.
jv16 wroteIf there would be a good method of producing even "mostly bug free" software, there would be "mostly bug free" software out there. I for one haven't ever seen any.
Well, I, for one, have seen plenty of software that is mostly bug free. So have you, if you'll only stop and think about it. Gosh, I just rode an operator-less airport shuttle from the concourse to the terminal thanks to software that is "mostly bug free". Frankly, I'm relieved that no one who shares your attitude about process had any hand in developing that software!
Needless to say, you don't need the same process sophistication to develop a simple utility suite like PowerTools as is required, say, to develop the on-board software for the space shuttle. Still, defending buggy software on the grounds that buggy software is ubiquitous is rather like an alcoholic rationalizing that his disease is not a problem on the grounds that alcoholics are numerous.
For me it feels
only when reporting bugs you'll get better software instead.
I wonder why the way of reporting bugs has changed?
Reporting this way makes it all - to my humble opinion - less transparant.
And we all know the effect
Ofcourse the 'bugtracker' is very convenient for the developer, however being and enduser of software you are being cuttoff.
You are cuttoff because you can not read anymore about the way end users deal with the bugs...
You are being cuttoff of bugs discussions...
Many users think - when running into a software problem - that's their own fault.
And in some cases that is true, however in many cases not. (So what now...)
And than we are talking again about the quality of software...
layman wroteWell, I, for one, have seen plenty of software that is mostly bug free. So have you, if you'll only stop and think about it. Gosh, I just rode an operator-less airport shuttle from the concourse to the terminal thanks to software that is "mostly bug free".
With an user interface of an operatorless airport shuttle you can't really tell how bug free its software is, can you really?
layman wroteNeedless to say, you don't need the same process sophistication to develop a simple utility suite like PowerTools as is required, say, to develop the on-board software for the space shuttle. Still, defending buggy software on the grounds that buggy software is ubiquitous is rather like an alcoholic rationalizing that his disease is not a problem on the grounds that alcoholics are numerous.
I am not defending a buggy software. I am only explaining why our products have small bugs but not critical ones.
Hanzie wroteReporting this way makes it all - to my humble opinion - less transparant.
And we all know the effect of less transparency ....
That is true, I'm afraid. But this Bug Tracker is still many times more transparent than with most companies who do not say a word about the bugs in their products. At least in our tracker regular users can even browse through the found bugs.
jv16 wroteI am only explaining why our products have small bugs but not critical ones.
This is an amusingly illogical statement, Jouni. And it goes to why I, for one, am finally giving up on your work. Except when "error seeding" is employed as part of the testing process, errors in software are all introduced inadvertently. If you could intentionally introduce only small bugs, then it would be possible, intentionally, to introduce no bugs at all. Safeguards only serve to catch critical bugs, not to prevent them. And if the workmanship was shoddy enough to introduce any critical bug in the first place, then it's shoddy enough to build a faulty safeguard.
In any event, when it comes to bugs, 'small' and 'critical' aren't opposites. Your software has bugs that are anything but small, however non-critical they may be. Good grief, man! You have been tinkering with this same basic functionality for ten years or more now. You may put it in a new jar each year, but it's the same stock functionality! Yet, you can release a version of the registry manager with major functional lapses and never even notice! How can anyone have been working on this stuff all these years and not have built up a scheme for regression testing that would prevent this sort of glaring gaffe?