Registry cleaners ???
I am constantly amazed or at leat I used to be that software vendors
cannot supply a decent removal tool that completely uninstalls their product. I mean, what's so hard about removing everything since they decided where to put it in the first place. Because it takes time to write code that does that, and their managers don't want them to take the time to do it. Who cares if the registry get bloated? I maintain software that is buggy as hell. It remains full of known bugs because managers don't want to bother fixing bugs that don't pop up very often. It's not the fault of the coders (for the most part). It's the bosses that say don't fix this, don't do that. It costs money to fix it, and it's not worth fixing. |
Registry cleaners ???
"Zootal" wrote in message
... | I am constantly amazed or at leat I used to be that software vendors | cannot supply a decent removal tool that completely uninstalls their | product. I mean, what's so hard about removing everything since they | decided where to put it in the first place. | | Because it takes time to write code that does that, and their managers don't | want them to take the time to do it. Who cares if the registry get bloated? | I maintain software that is buggy as hell. It remains full of known bugs | because managers don't want to bother fixing bugs that don't pop up very | often. It's not the fault of the coders (for the most part). It's the bosses | that say don't fix this, don't do that. It costs money to fix it, and it's | not worth fixing. | | Your point is noteworthy, yet subject to further commentary. It IS the fault of the "coders" as writing software that is "good" software the first time around takes a concerted effort, and too many are either lazy or not sufficiently skilled to do it right in the first place. I realize there are deadlines and project cost constraints, I used to write a lot of software, but such excuses are insufficient to justify badly written software. I deal, in my business, with software people quite often and am surprised (and disconcerted) to find out how few know how to create a top-down structured flowchart for their software (probably because such was never done, and trust me, software becomes a spaghetti mess quite quickly when written without some underlying flowcharting effort in the beginning). In particular, it is quite easy to delete an entire registry key without having to track individual data value entries stored beneath that key, and many uninstall programs fail to do this. How many times have you uninstalled/reinstalled a program only to find all of your "original" settings are still there? This is due to an entire registry key (and data values stored under that key) under HKLM/software/suppliername/productname or HKCU/software/suppliername/productname still remaining in the registry after the uninstall occurs. -- Best regards, Kyle |
Registry cleaners ???
"Kyle" wrote in message ... "Zootal" wrote in message ... | I am constantly amazed or at leat I used to be that software vendors | cannot supply a decent removal tool that completely uninstalls their | product. I mean, what's so hard about removing everything since they | decided where to put it in the first place. | | Because it takes time to write code that does that, and their managers don't | want them to take the time to do it. Who cares if the registry get bloated? | I maintain software that is buggy as hell. It remains full of known bugs | because managers don't want to bother fixing bugs that don't pop up very | often. It's not the fault of the coders (for the most part). It's the bosses | that say don't fix this, don't do that. It costs money to fix it, and it's | not worth fixing. | | Your point is noteworthy, yet subject to further commentary. It IS the fault of the "coders" as writing software that is "good" software the first time around takes a concerted effort, and too many are either lazy or not sufficiently skilled to do it right in the first place. I've been a software developer for over 20 years, and more then half of the "programmers" I've worked with were poorly qualified at best. Is it the coders fault? Whose fault is it when management hires an unqualified programmer (because they are cheap or because they need token miniorities or because the H1B people work for peanuts but are poorly qualified ) and they write crap code? This happens *all the time*. I have worked with a lot of nice decent people that should never be allowed to touch a keyboard. I sit next to a programmer that brags about his MIS degree. If you know anything about MIS degrees, they do not qualify you to be a programmer. I'm not saying it's not entirely the fault of the coder - but what can we do when half the coders out there don't know what they are doing and management doesn't care or doesn't see it? |
Registry cleaners ???
"Kyle" wrote in message ... "Zootal" wrote in message ... | I am constantly amazed or at leat I used to be that software vendors | cannot supply a decent removal tool that completely uninstalls their | product. I mean, what's so hard about removing everything since they | decided where to put it in the first place. | | Because it takes time to write code that does that, and their managers don't | want them to take the time to do it. Who cares if the registry get bloated? | I maintain software that is buggy as hell. It remains full of known bugs | because managers don't want to bother fixing bugs that don't pop up very | often. It's not the fault of the coders (for the most part). It's the bosses | that say don't fix this, don't do that. It costs money to fix it, and it's | not worth fixing. | | Your point is noteworthy, yet subject to further commentary. It IS the fault of the "coders" as writing software that is "good" software the first time around takes a concerted effort, and too many are either lazy or not sufficiently skilled to do it right in the first place. I realize there are deadlines and project cost constraints, I used to write a lot of software, but such excuses are insufficient to justify badly written software. I deal, in my business, with software people quite often and am surprised (and disconcerted) to find out how few know how to create a top-down structured flowchart for their software (probably because such was never done, and trust me, software becomes a spaghetti mess quite quickly when written without some underlying flowcharting effort in the beginning). Jacksons Structured Programming springs to mind. When i was learning the black art of COBOL programming many moons ago we *had* to produce a flowchart ON PAPER and dry run it, again on paper before we where allowed anywhere near a keyboard ! Just my 2 cents worth In particular, it is quite easy to delete an entire registry key without having to track individual data value entries stored beneath that key, and many uninstall programs fail to do this. How many times have you uninstalled/reinstalled a program only to find all of your "original" settings are still there? This is due to an entire registry key (and data values stored under that key) under HKLM/software/suppliername/productname or HKCU/software/suppliername/productname still remaining in the registry after the uninstall occurs. -- Best regards, Kyle |
Registry cleaners ???
On Thu, 19 Mar 2009 18:49:08 -0000, "Mick" wrote:
Jacksons Structured Programming springs to mind. When i was learning the black art of COBOL programming many moons ago we *had* to produce a flowchart ON PAPER and dry run it, again on paper before we where allowed anywhere near a keyboard ! Just my 2 cents worth And your two cents worth is probably now about 21 cents due to inflation since those days. I never learned COBOL but I did a fair amount of PL/1 programming. I also remember those days. People were "cheap" and "machine time" was expensive. Now those economics have completely flipped around. I've worked with software developers for probably 20+ years now, and I appreciate the pressures on them to release on schedule, to get a product out without the resources that they know they need, etc. Then there are those developers that think they "know the marketplace" better than the marketing people, so they spend a lot of time on "cool features" that no one cares about, but introduce bugs of their own, etc., etc., etc. In particular, it is quite easy to delete an entire registry key without having to track individual data value entries stored beneath that key, and many uninstall programs fail to do this. How many times have you uninstalled/reinstalled a program only to find all of your "original" settings are still there? This is due to an entire registry key (and data values stored under that key) under HKLM/software/suppliername/productname or HKCU/software/suppliername/productname still remaining in the registry after the uninstall occurs. Isn't this problem exactly what the registry cleaners are supposed to solve? -AH -- Best regards, Kyle |
Registry cleaners ???
On Thu, 19 Mar 2009 22:46:34 -0700, Andrew Hamilton
wrote: I never learned COBOL What good fortune! Peter Finney Liphook Hampshire England |
Registry cleaners ???
"Mick" wrote in message
... | | Jacksons Structured Programming springs to mind. | When i was learning the black art of COBOL programming many moons ago we | *had* to produce a flowchart ON PAPER | and dry run it, again on paper before we where allowed anywhere near a | keyboard ! | Just my 2 cents worth | I mentioned "flowcharting" for a good reason, as an experienced flowcharter/programmer will readily concede, if it works on paper then the probability that it will work in real code is very high. In fact, tho I was not seriously fond of flowcharting, I fortunately learned early on that when the time was taken to flowchart a project in the beginning, the end coding/debugging time was significantly reduced versus the "jump in there and cut some code" approach. Heh, I suppose your COBOL days were back in the day when CPU time was billed/paid-for in tenths of seconds eh? Thank the Lord I did not have to learn much more than that COBOL used verbs and subjects names and such, lol. My upbringing in the software world coincided nicely with the introduction of the Intel 4004, 8008 and 8080 (late 70's) so my painful experiences with mainframe and mini-computer setups was, quite fortunately, limited to one deck of punch-cards dropped on the floor at college. A seasoned veteran typically has many juicy "dropped deck" or "deck destroyed by punch card reader" stories. Regarding the other posts about the quality of programmers, I have no doubt that some are not really good code-cutters. I experienced such when I worked as an engineer for GM. Many good people, not that many really good programmers. Of particular consideration though is the never ending progress of the computing world. Noting that the computing world's "state of technology" is constantly in the process of evolution, I do sympathize with programmers from the perspective that one must continually discard old and reliable (and well known) tools and start anew and learn to use new programming tools (most with their own new set of bugs/character flaws), which process creates its own new challenges/headaches/learning booboos. As to products such as installers and in particular the Microsoft Installer, all I can say is what a miserably conceived POS (and yes, I have taken a look at its underlying capabilities during a painful time when I experienced the malady of every time I restarted my win2k system the MS Installer fired up 4 or 5 times trying to install some program that was already installed). Whenever a software tool requires mastery of a cryptic set of commands, the outcome is not surprisingly what we see with the MSI installer/uninstaller problem arena. It's no wonder the registry is a mess after taking a hard look at MSI. In fact, I nowadays get a warm-fuzzy when I see a new program I am installing does NOT use MSI. -- Best regards, Kyle |
Registry cleaners ???
"Kyle" wrote in message ... "Mick" wrote in message ... | | Jacksons Structured Programming springs to mind. | When i was learning the black art of COBOL programming many moons ago we | *had* to produce a flowchart ON PAPER | and dry run it, again on paper before we where allowed anywhere near a | keyboard ! | Just my 2 cents worth | I mentioned "flowcharting" for a good reason, as an experienced flowcharter/programmer will readily concede, if it works on paper then the probability that it will work in real code is very high. In fact, tho I was not seriously fond of flowcharting, I fortunately learned early on that when the time was taken to flowchart a project in the beginning, the end coding/debugging time was significantly reduced versus the "jump in there and cut some code" approach. Heh, I suppose your COBOL days were back in the day when CPU time was billed/paid-for in tenths of seconds eh? Thank the Lord I did not have to learn much more than that COBOL used verbs and subjects names and such, lol. My upbringing in the software world coincided nicely with the introduction of the Intel 4004, 8008 and 8080 (late 70's) so my painful experiences with mainframe and mini-computer setups was, quite fortunately, limited to one deck of punch-cards dropped on the floor at college. A seasoned veteran typically has many juicy "dropped deck" or "deck destroyed by punch card reader" stories. Regarding the other posts about the quality of programmers, I have no doubt that some are not really good code-cutters. I experienced such when I worked as an engineer for GM. Many good people, not that many really good programmers. Of particular consideration though is the never ending progress of the computing world. Noting that the computing world's "state of technology" is constantly in the process of evolution, I do sympathize with programmers from the perspective that one must continually discard old and reliable (and well known) tools and start anew and learn to use new programming tools (most with their own new set of bugs/character flaws), which process creates its own new challenges/headaches/learning booboos. As to products such as installers and in particular the Microsoft Installer, all I can say is what a miserably conceived POS (and yes, I have taken a look at its underlying capabilities during a painful time when I experienced the malady of every time I restarted my win2k system the MS Installer fired up 4 or 5 times trying to install some program that was already installed). Whenever a software tool requires mastery of a cryptic set of commands, the outcome is not surprisingly what we see with the MSI installer/uninstaller problem arena. It's no wonder the registry is a mess after taking a hard look at MSI. In fact, I nowadays get a warm-fuzzy when I see a new program I am installing does NOT use MSI. -- Best regards, Kyle I too learned flow charting, basic and COBOL, was going to learn FORTRAN, but opted out for 8088 Machine language (actually learned 8010 (comodore) ) which I loved and gave me a good sense of what a processor was all about but sigh, dont remember much now Pokeyman |
All times are GMT +1. The time now is 01:03 PM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
HardwareBanter.com