Quality of PowerTools (was: Del button .. no function)

redseujac

redseujac wrote
...

2. With the raw list after selecting some entries and pressing the keyb DEL-button, the backup message pops up. After answering Yes and then clicking OK the selected entries keep selected and nothing happens furthermore...

Hey Jouni, is this also fixed? And not only the keyb DEL-button issue with the "Structured list"?

mrcs

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

jv16

redseujac wrote
redseujac wrote...

2. With the raw list after selecting some entries and pressing the keyb DEL-button, the backup message pops up. After answering Yes and then clicking OK the selected entries keep selected and nothing happens furthermore...

Hey Jouni, is this also fixed? And not only the keyb DEL-button issue with the "Structured list"?

Yes, this bug is also fixed. Good catch!

jv16

MRCS wrote

I also still have a real issue with two items I mentioned before. They were deemed "improvements," but I don't think spending a lot of time on semantics and bypassing the issue really moves the board's conversation forward. After all, Macecraft did refocus the forum because they want feedback which, as another poster commented, we are taking our time to do . That said, I don't think defining a critical bug as one where "the user is forced to re-install Windows" sets the bar very high, especially for a company with the fine reputation of Macecraft.

We are very happy to get feedback, but in this case the whole discussion started with "Sorry to say but I regret I bought version 2009 it looks like a beta considering all the bugs". That's not feedback that is very usefull.

MRCS wrote

A "feature" (call it whatever you want) that was present in previous releases and then that function is lost may not be a bug, but if it makes the product nearly unusable it's at least a problem. Now if Macecraft removed it intentionally, that's okay. It's their product and they can do whatever they want with it. Removing the Select Highlighted is a problem and perhaps prohibitively time consuming if you have a 100+ items and have to check each one individually.

The "Select Highlighted" was removed by accident. And I just re-added it to the Registry Cleaner, it will be again present in the next released version due out later in this month.

redseujac

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

hanzie

--clip--

I did not start the discussion with "Sorry the say... The sentence above was and is a personal conclusion.

Nothing more or less.

I reported the del keyb button not functioning. Thanks to this posting, 2 bugs could be solved in cooperation with other users/testers (In other words: thanks for the feedback, instead of ... not very usefull)

I criticize, because I think that there are too many bugs, it feels like a beta, not only for me..

I critisize Macecraft the way they are dealing with or appreciating their customers.

It takes time to write, post, and giving replies again. Thanks to the customers who are reporting, Macecraft will be able to develop and troubleshoot their software in a better way. Thanks, ... take this into account, is what I am saying, nothing more nothing less.

The way jv16 is giving feedback, ignoring details of users, tells me something about his empathy towards the users and their postings. When there are many bugs, users do not appreciate the software that much.

The vision never can be: because there are always bugs in software (powertools) users of the software must accept this. It never can be: you do not agree (?) leave it. That is the world upside down.

As: the more bugs, more annoying...

The presence of bugs is telling (me) something about the quality and the release of the software.

(As in games, when released to early)

Something has been said about two options: the fix and the delete function , the developer only recommends the fix

function..

In order to delete (safely) the VBE items, you have to use the agressive mode. Not very logical to me.

There are more items - in the agressive mode - that can be deleted safely.

(My remark-joke: if you want hearing more about that. An update of my posting will cost Macecraft € 3,0)

I am still using the 540 version, despite the fact that there are refresh problems (deleted items remain on the screen). I can live with that. I can live with some bugs, no problem. I only wonder how the software has been tested.

I mentioned two other software programs that will do the job good or even better, I doubt if I will use powertools

in future, considering the way it is working(less)now.

I can live with bugs in software to a certain extend.

I can not live with the fact feedback being removed in case a moderator/ developer does not like the answer.

In that case it is shortage of words, to my opinion.

And again. Kind Regards. Hanzie

jv16

All the issues are already answered before in this thread.

mrcs

Hanzie wrote
...users...developers...

I believe feedback on feedback, smoothing out the process, can be just as valuable as feedback on the software, although reasonable people might disagree.

On first thought it might seem like having a developer also monitoring the boards would be a good idea. But for those of us, both users and developers, who are highly involved (dare I say, intimate) with their computers, we can be very sensitive. I must admit, as I did, my first reaction was shock...but I got over it, as most people do. My observations of objective moderators (as, by definition, they should be), is that they understand what can be the personal nature of computing, to filter out the good ideas from the bad, and to pass them up the line.

The knife cuts both ways : I didn't find comments such as "That is why it's called jv16 PowerTools" and "you are warned against using it", too terribly "useful" either.

As for the software itself, I've now had a chance to look at the curiously named 'raw' view. I thought the 'structured' view was an updated version of the old releases. The raw view, perhaps more aptly named 'classic' view, gave me most everything I needed and didn't present the problems I found with the structured view. I didn't initially explore the raw view because, I guess, in the back of my mind I was thinking it was a derivative of the old view and might be something like a direct disk view, such as with Disk Editor. For those who are upgrading a more descriptive name would be helpful. Those who have already been using the upgrade for a while don't need the help; they already know what it does.

Now that I have discovered the raw view, I only have two items of interest. On a fully patched, updated and hardware, software firewall protected system, ActiveX is by far the greatest security risk, which is one of the reasons I feel it necessary to "play with fire." The response to my previous attempt to open this topic seemed to imply that I acted on what was shown causing myself a problem, I didn't. Even though the current scanning engine is undoubtedly different, neither RegSupreme nor pre-RegSupreme releases showed the erroneous results, besides me knowing they were something I didn't want to delete. Just feedback that you may want to take another look at that.

Is there a "Just to be safe" file, or is that now a part of the code? I looked at all the .dat files and didn't see anything like that. With earlier versions of jv16, and over time as I became more familiar with the software, I pared it down to where I wasn't using it at all. If something like that is no longer available, you might want to consider re-adding it for more advanced users - with all the appropriate warnings and admonitions not to mess with it. Even if it's not editable, at least we would know what categories are being filtered out.

layman

jv16 wrote
The design goal of PowerTools is not to be bug-free, because such thing is simply impossible. Instead, the design goal is to make sure the bugs are non-critical, like this one for example.

As a professional software developer for the past 46 years, I simply cannot leave this comment unremarked. I've observed you for years now, Jouni, and I have to say that you remain amateurish in many respects. How preposterous it is to use the term "design goal" with reference to bugs, whatever the severity of the bugs you have in mind! The presence of bugs in software is a failure, not of the software, but of the process used to produce it. However true it may be that we can never be sure a software artifact is free of defects, "defect-free" is nevertheless a sensible ideal as we strive toward "good enough." What you are calling "non-critical" defects have an economic cost to your customers, for pete's sake! Your company is not paying the cost of the hours wasted due to confusion, head-scratching, and wheel-spinning these defects, "non-critical" or otherwise, are causing out in the real world. Maybe that explains your cavalier attitude about supposedly unimportant bugs, but I find that attitude appalling and unprofessional.

As I said, all defects, regardless of severity, represent a failure -- a failure of the development process and its management. Defects represent rework, and time and again you are releasing software that requires an intense six months or more of rework once you've shipped, just to get the software to a semblance of stability. What is up with that?!!! For one thing, it should suggest to Macecraft that something is wrong with their business model - a model that depends on these not-ready-for-prime-time releases to goose the revenue stream. Whether or not you like to admit it to yourself, you are slapping this stuff together and foisting product prematurely on your customers. You apparently need help in coming to an understanding of what it means to manage a product by managing the development process, and the importance of quality control in the overall scheme of things! That knowledge is not some arcane secret. It is freely available to anyone who cares to take software craftsmanship above the level of a tech-weenie working in his basement. As things now stand, your annual-release operation is somewhat like a dog chasing its tail. Since you spend half a year on frantic rework, you have only half a year to pull together the next release, which turns out to be about six months less than what is actually needed. What is wrong with this picture? I leave the answer as an exercise for the reader.

jv16

Thank you for your feedback layman.

layman wrote

...The presence of bugs in software is a failure, not of the software, but of the process used to produce it. However true it may be that we can never be sure a software artifact is free of defects, "defect-free" is nevertheless a sensible ideal as we strive toward "good enough."..

So in other words, you too seem to agree that there is no such thing as bug free software, and you say we should strive toward "good enough". That's exactly what we do, by "good enough" I mean a software that does not have any serious problems.

If you disagree, we can continue this discussion if you can name a few constantly updated (i.e. product is being improved and new features are being added) 200.000+ source code line software product that does not contain any bugs.

Until you can do that, I repeat my case: There is no such thing as bug free software. In this reality, it is my job to make sure that the bugs and problems that do occur, are non-critical and cause as little inconvenience to the user as possible. And there has not been a single critical bug in PowerTools since the very first versions of PowerTools 2008, and that was a freak accident, before that, I don't even remember.

And by the way, here are Macecraft's official definitions for bug severity (we will be releasing a new, public Bug Tracking system and these definitions will also be used there):

1. Critical bug - A bug that can cause damage to user's computer in that extent that it's possible the user must re-install Windows in order to recover. The bug must occur automatically, that is, without any interaction from the user.

For example, if simply running the Registry Cleaner (i.e. without touching the Delete button) would cause damage to the system, this would be classified as a critical bug.

2. Serious bug - A bug that can cause damage to user's computer but only via action by the user.

For example, if the Registry Cleaner would list a non-invalid, important registry keys as errors, this would be classified as a serious bug.

3. Normal bug - A bug that can, at least in theory, cause damage to user's computer with action by user, or if some feature works with clearly reduced performance under certain conditions, or if some feature of the program does not work properly.

For example, if the Registry Cleaner would list a non-invalid but not important registry keys as errors. Or, if the user uses the File Finder and the results contain critical system files, the prodcut should always warn the user against removing or modifying these system files. Or, if the Registry Cleaner takes over 10 minutes to run under certain Windows setup. Or, if under some systems the Registry Cleaner doesn't start at all when user clicks the Start button. These would be classified as normal severity bugs.

2. Minor bug - a bug that on all systems causes inconvenience to the user, but does not make any features fully unusable.

For example, if the Quick Tutorial's Language selection would remain empty even if translations do exist. This would be classified as minor bug if the Language menu in the main window works, if also the Language menu wouldn't work, it would be classified as a normal bug.

1. Cosmetic - a bug that causes inconvenience to the user on some systems only, or on all system causes very minor inconvenience.

For example, typos are classified as cosmetic issues.

leonardo

layman wrote

..................The presence of bugs in software is a failure, not of the software, but of the process used to produce it. However true it may be that we can never be sure a software artifact is free of defects, "defect-free" is nevertheless a sensible ideal as we strive toward "good enough." What you are calling "non-critical" defects have an economic cost to your customers, .....................

Hear Hear !!

redseujac

Just one little thought in this discussion.

I repeat it was at least regrettable that the most recent (whether or not serious) bugs happened, namely the ones regarding the backups (e.g. in Registry Cleaner) and the Startup Manager, where simply things of the 64-bit version were mixed with the 32-bit part (which was working well before).

Those bugs caused some programs not starting up anymore at boottime and backups couldn't be restored properly. That is not nothing.

I still think such things should not happen and seem to show lack of order or attentiveness and concentration and maybe for some people give an impression of amateurism.

If Macecraft wants to have/keep a professional imago such things should never happen again.

Fortunately the bugs were fixed immediately with a quick update release after some alert users had reported them here.

jv16

redseujac wrote

Those bugs caused some programs not starting up anymore at boottime and backups couldn't be restored properly. That is not nothing.

I still think such things should not happen and seem to show lack of order or attentiveness and concentration and maybe for some people give an impression of amateurism.

If Macecraft wants to have/keep a professional imago such things should never happen again.

I agree with everything you say. And before we release the next version, its Safety Net feature will be improved to make sure problems like these will not happen ever again.

redseujac

Well, that's a nice pledge Jouni!

Thanks anyway and ... keep up the

good

work :

layman

jv16 wrote
... I repeat my case: There is no such thing as bug free software. In this reality, it is my job to make sure that the bugs and problems that do occur, are non-critical and cause as little inconvenience to the user as possible.

We who develop software are supposed to deal in logic, and so the fallacy of the above should be obvious to you. It is certainly true, as you say, that we can never be sure that we've removed all those inadvertently-introduced bugs. And for precisely the same reasons that is so, we similarly cannot "make sure" that we've removed the bad defects while leaving only a residue of insignificant ones. I really don't wish to beat you over the head with the fallacies of your own thinking, but your comments reveal a mind-set that goes a long way to explain the quality problems you are experiencing.

jv16

layman wrote
jv16 wrote... I repeat my case: There is no such thing as bug free software. In this reality, it is my job to make sure that the bugs and problems that do occur, are non-critical and cause as little inconvenience to the user as possible.

We who develop software are supposed to deal in logic, and so the fallacy of the above should be obvious to you. It is certainly true, as you say, that we can never be sure that we've removed all those inadvertently-introduced bugs. And for precisely the same reasons that is so, we similarly cannot "make sure" that we've removed the bad defects while leaving only a residue of insignificant ones. I really don't wish to beat you over the head with the fallacies of your own thinking, but your comments reveal a mind-set that goes a long way to explain the quality problems you are experiencing.

I got your point, so please let me rephrase: There is no such thing as bug free software. In this reality, it is my job to make sure the most of effort and resources are directed in a way the probability of a critical bug occurring in a released software is very small, even as this causes less critical bugs to appear more often in released versions. More often compared to a theoretical situation where we wouldn't have such focus on preventing serious bugs.

This means that there are numerous safety layers, checks, double checks and components whose only function is to make sure nothing goes wrong, and if something seems to be wrong, the program shows an error message and quits before any harm is caused to the user's system.

jv16

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

mrcs

This has got to be the strangest board I've ever seen (now you know why I rarely participate) -- the preference seems to be a lot of verbage about everything *but* the software, which I thought was the purpose of a forum. Does anyone out there care to answer my previous simple question, yes or no: Is there a "Just to be safe" file or something comparable?

layman

jv16 wrote
This means that there are numerous safety layers, checks, double checks and components whose only function is to make sure nothing goes wrong, and if something seems to be wrong, the program shows an error message and quits before any harm is caused to the user's system.

Incorporating assumption-checking safeguards in your software is commendable, but they aren't a substitute for quality control. Consider this: when you design in software safeguards, you are focusing on your product, rather than your process. And since defects are a process failure, no software safeguard will serve to treat the root cause of a defect. So long as you concentrate on the product rather than the process, you won't make much headway on quality. I'd encourage you to read up on "defect removal efficiency" and think about how that metric could serve as a basis for thinking analytically about your process.

jv16

MRCS wrote
This has got to be the strangest board I've ever seen (now you know why I rarely participate) -- the preference seems to be a lot of verbage about everything *but* the software, which I thought was the purpose of a forum. Does anyone out there care to answer my previous simple question, yes or no: Is there a "Just to be safe" file or something comparable?

I guess you refer the Ignore List file of the old RegCleaner? Then the answer is "yes and no". Yes, there is both an built-in Ignore List that filters out certain kinds and types of errors for improved safety, but no, you cannot modify or even see the list. But you can make additions to the list by using the Registry Cleaner's "Ignore Words" tab.

« Previous Page Next Page »