HardwareBanter

HardwareBanter (http://www.hardwarebanter.com/index.php)
-   Asus Motherboards (http://www.hardwarebanter.com/forumdisplay.php?f=15)
-   -   Registry cleaners ??? (http://www.hardwarebanter.com/showthread.php?t=176478)

Zootal March 19th 09 01:31 AM

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.



Kyle March 19th 09 01:56 PM

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


Zootal March 19th 09 07:29 PM

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?



Mick[_6_] March 19th 09 07:49 PM

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




Andrew Hamilton March 20th 09 06:46 AM

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



Peter Finney March 20th 09 12:47 PM

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

Kyle March 20th 09 04:26 PM

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


pokey man March 21st 09 02:47 AM

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