Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

   Home   Help Search  
Pages: [1]   Go Down
  Print  
Author Topic: HRD, LLC still in business  (Read 6829 times)
N8DV
Member

Posts: 60




Ignore
« on: October 22, 2012, 06:24:25 PM »

I have sent several emails to HRD, LLC trying to find out if the new program 6.0 is close to release. I have not received any replies.
I then tried their support email and it's dead. There hasn't been any updates since August to HRD. It's now end of October and nothing.
I was just wondering if they are still open for business and developing HRD. Anyone have an ideas?  Thanks.
Logged
STAYVERTICAL
Member

Posts: 854




Ignore
« Reply #1 on: October 23, 2012, 12:38:54 AM »

Maybe HRD V6 is a stalking horse?

Your guess is as good as mine.
Perhaps the forums will help you.
They seem to release regular advertisements on QRZ.com, so something is surely happening.
I am sure they are still developing V6 since they say they have a few thousand paying hams already signed up.
Guess they are just making sure the bugs are ironed out before release (impossible with software but can be minimised).

Good luck.

73 - Rob
Logged
KF7CSO
Member

Posts: 325




Ignore
« Reply #2 on: October 23, 2012, 05:07:32 AM »

The latest version of a newsletter they send out was 10/19/12, four days ago. I had emailed them about a small issue two weeks ago on a Saturday or Sunday (I didn't go look) and a person emailed me back within an hour. I did purchase 6 so I don't know if that bumped me up the ladder or not.  Wink
Logged

Eric
AA6YQ
Member

Posts: 1584


WWW

Ignore
« Reply #3 on: October 23, 2012, 02:17:53 PM »


Guess they are just making sure the bugs are ironed out before release (impossible with software but can be minimised).


Asserting that its impossible to remove all known defects from software is a self-fulfilling prophecy. You should expect all known defects in your software to be corrected before its release, and you should expect newly-discovered defects to be corrected within a week.

If the HRD team is correcting all known defects before making their first release, they are doing the right thing for the HRD user community, and for amateur radio software in general.

    73,

        Dave, AA6YQ
Logged
STAYVERTICAL
Member

Posts: 854




Ignore
« Reply #4 on: October 23, 2012, 06:03:13 PM »


Guess they are just making sure the bugs are ironed out before release (impossible with software but can be minimised).


Asserting that its impossible to remove all known defects from software is a self-fulfilling prophecy. You should expect all known defects in your software to be corrected before its release, and you should expect newly-discovered defects to be corrected within a week.

If the HRD team is correcting all known defects before making their first release, they are doing the right thing for the HRD user community, and for amateur radio software in general.

    73,

        Dave, AA6YQ

You are quite right Dave,
I was thinking of my time in software development, and I should not paint everyone with that personal brush.
But as you no doubt know, there are other factors in play apart from software resilience - ones which are economically mandated.
It has to be released sometime, and there will be bugs - best intentions notwithstanding.

Bugs are typically not "known defects", that is why they are found after a release - but of course the HRD guys will do the best they can.
Communication is the key to understanding, both received and given.
In my corporate experience, not communicating with users is an "elephant in the room" event.
It may not be pleasant to see disappointment and receive flak for unpopular news, but it pales to insignificance compared to keeping users in the dark.

Consider you are waiting for a plumber who said he would be there at 10am.
As 10am comes and goes, with nothing heard, you are getting more and more annoyed, leading to an eruption when he finally arrives.
This guy will need to do a lot of fast talking to regain his reputation.

If the guy called at 9.30am and explained that he would be two hours late, he will likely get an earful, but at least you now know what is going on, defusing the situation.
The simple act of not keeping customers informed, even it the news is bad, is an avoidable cost to business in many companies.

I am not saying HRD is not communicating, since I am not privy to this information, but am just making a general comment on business practices.


73 - Rob
Logged
W4PC
Member

Posts: 283


WWW

Ignore
« Reply #5 on: October 28, 2012, 12:52:50 AM »

Fred, found your email in my junkmail.. will reply..

Yes, of course we're still in business. Just head down into code Smiley

Rick - W4PC
Logged
N8DV
Member

Posts: 60




Ignore
« Reply #6 on: October 28, 2012, 11:03:36 AM »

UPDATE: Did finally get an answer to my email. It was in their "junk" inbox.  It stated that HRD 6.0 was with the beta team.
Anyway, new software is issued and if need be, updates to the software are issued. You will never have bug free software.
Logged
AA6YQ
Member

Posts: 1584


WWW

Ignore
« Reply #7 on: October 29, 2012, 01:33:23 AM »

You will never have bug free software.

False: there are provably correct, defect-free, non-trivial applications. Compilers for rigorously-defined programming languages, for example.

Asserting "You will never have bug free software" is like a baseball coach saying "we will never have error-free games": it's a self-fulfilling prophecy. Aim low, and you'll hit the ground every time.

It is certainly practical - and economically advantageous - to repair all reported defects in an application. It is also practical to put in place infrastructure that enables a newly-reported defect to be rapidly isolated and repaired in a new version made available to the user community.

    73,

         Dave, AA6YQ

Logged
KB3TWH
Member

Posts: 16




Ignore
« Reply #8 on: November 02, 2012, 03:52:17 AM »

False: there are provably correct, defect-free, non-trivial applications. Compilers for rigorously-defined programming languages, for example.

Hmm, what languages do you refer to?   As a developer who's been doing code for a long time, I'd like to meet that language that will always correct logic problems (a == b instead of a != b as a trivial example).   Programs/compilers are written by imperfect beings (us/humans), and as we are prone to making mistakes, our inventions will have mistakes.

Logged
AA6YQ
Member

Posts: 1584


WWW

Ignore
« Reply #9 on: November 02, 2012, 03:41:28 PM »

False: there are provably correct, defect-free, non-trivial applications. Compilers for rigorously-defined programming languages, for example.

Hmm, what languages do you refer to?   As a developer who's been doing code for a long time, I'd like to meet that language that will always correct logic problems (a == b instead of a != b as a trivial example).   Programs/compilers are written by imperfect beings (us/humans), and as we are prone to making mistakes, our inventions will have mistakes.


My claim above does not assert or imply that there exists a compiler that can detect all defects in an application being compiled. To cite an example of a defect-free non-trivial application, I pointed out that there are defect-free compilers: compilers that provably contain no defects.

It's certainly true that no human writes defect-free code. However, there is an array of techniques to discover and eradicate most of these defects early in the development cycle, e.g. resilient/testable architectures, unit testing, scenario testing, static analysis, dynamic analysis, functional testing, performance testing, and code coverage analysis. Applications can also be designed to detect defects at runtime, to log and convey information that accelerates defect isolation, and to gracefully recover.

Applying the above techniques can dramatically reduce the number of latent defects in an application, and can dramatically reduce the time between defect report and deployed correction to days or hours. This requires an intense focus on product quality from the first development iteration, and it requires high expectations from the user community.

Proclaiming "you will never have bug free software" just provides an excuse to be sloppy.
Logged
KD0REQ
Member

Posts: 896




Ignore
« Reply #10 on: November 02, 2012, 03:56:39 PM »

printf "Hello World" is going to be problematic for lots of programmers, frankly.  the libraries are wrong.  or the interface is dev/null.  or it's not the person's home language.  or you have a virus on the PC that has interrupted 32 services, 6 of which are in the display chain.

you take what you get, work around what you can, and report service-affecting bugs with the right priority, and any good outfit that wants to be around for the 1st anniversary will fix things and upgrade the code as they can.

not that I'd know anything about working around the clock to figure out why things don't work....
Logged
KB3TWH
Member

Posts: 16




Ignore
« Reply #11 on: November 03, 2012, 08:53:04 AM »


My claim above does not assert or imply that there exists a compiler that can detect all defects in an application being compiled. To cite an example of a defect-free non-trivial application, I pointed out that there are defect-free compilers: compilers that provably contain no defects.

It's certainly true that no human writes defect-free code. However, there is an array of techniques to discover and eradicate most of these defects early in the development cycle, e.g. resilient/testable architectures, unit testing, scenario testing, static analysis, dynamic analysis, functional testing, performance testing, and code coverage analysis. Applications can also be designed to detect defects at runtime, to log and convey information that accelerates defect isolation, and to gracefully recover.

Applying the above techniques can dramatically reduce the number of latent defects in an application, and can dramatically reduce the time between defect report and deployed correction to days or hours. This requires an intense focus on product quality from the first development iteration, and it requires high expectations from the user community.

Proclaiming "you will never have bug free software" just provides an excuse to be sloppy.

I agree with everything you say here.   We use all of these techniques at work.  I mis-understood your first statement about 100% bug-free, I thought you were referring to the entire program, and not just the compiler.   
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!