Infotainment System Software - The Look of Junior Programmers
#1
Infotainment System Software - The Look of Junior Programmers
This is long. Apologies. It's about the fewest words I could use, and convey the message properly… If you don't own a bike with a new Infotainment Boom Box! radio, this isn't for you, anyway…you're welcome to read it. But the focus is others, like myself, who own a '14 or '15 Rushmore model...
I was a programmer for a number of years. I even had my own software company. I have supervised software engineers, including hiring them… I have some software background, in other words.
I have a premium 6.5 GT Infotainment radio on my 2014 SG. Earlier, I had a 4.3 model.
Today, I was pulled over for an inspection by LEOs. No issues, but when I started up to pull away, I didn't want my stereo to come on blasting. (No matter where I leave the volume set at shutdown, the radio seems to come on after being off a while at a fairly loud volume).
So as the bike's firing up and the graphic starts on the radio screen, I'm pushing the volume toggle down repeatedly to try and catch the volume as quick as I can, and turn it down, as the radio boots up…
The radio not only turned the volume down…it went into a mode where I had NO volume control any longer. Pushing up…or down…on the volume toggle had no effect. I had to cycle the radio off/on to restore the volume function.
After I got home (I was headed home, from work when this happened), it occurred to me this kind of failure…where the user causes a problem by doing something you (the programmer) didn't plan for or expect them to do…is reminiscent of my experience with 'junior' programmers of other systems.
Namely, as a programmer you spend a good deal of your time protecting software with which humans interact directly, from erroneous inputs, limiting what a user can actually do to mess you (the software) up. Example: Me pressing the volume toggle down a jillion times shouldn't have resulted in a system failure…my 'extra' presses should have been ignored. ...And the software of a good programmer would have handled the event in stride.
The software in my 6.5 system has a lot of 'holes' in it. Like this one. Rather than stopping acting upon my inputs once I got to 'zero' volume, the software appears to have allowed my excessive 'down' toggles, processed them, and subsequently went into some weird state as a result…probably what's called an 'unhandled exception'.
This is the type of software snafu 'new' and inexperienced programmers are famous for. (My presumption is the people who are writing the software for our systems are qualified to do so, by education, etc., but that they don't have a great deal of experience…versus that the programmers are simply incompetent.)
A small software enterprise is particularly susceptible to this type of thing, i.e., assigning a new project to a 'green' programmer. Because they're essentially short-handed. There are no real 'trainees' in such an outfit. (New Guy will work for less money than Seasoned Guy, BTW--an inducement to a small shop to hire New Guy versus Senior Guy).
The control software for our systems is not a major undertaking. It's the type of software project that would be a challenge for a new person with a solid education, but would certainly not be beyond them. But what you'll see…what we're seeing in fact, I believe…is a control system written by a newbie, a system that works well about 90% of the time…but that is as 'buggy' as a flop-house mattress, when you get down to the fine-points.
So that's my theory. That's why we're seeing the issues we're seeing. Some things are one-time occurrences (because the sequence of events that produce them--like my toggle-strokes today--don't occur frequently). Some things happen frequently--like the auto-dimming function (or so it seems to be this function) keeping the screen brightness at a bare minimum such that you can't see anything on the radio screen, for about 10 minutes after power up.
If you're still with me, thanks. Now to the point. None of us should accept this situation. I am making a list of my radio's faults, and taking them to the dealer with the expectation that they'll be fixed under warranty. I urge those of you who are experiencing problems to be proactive as well. Rather than wait for fixes (which might never come), I encourage you to do what I'm doing, and make your faults known to the dealers. They, in turn, can pass these on to the MoCo…who can present the 'bug reports' to the contractor who's produced this fine piece of software. (I don't think we should cut them, or the MoCo any slack. We were charged a 'premium' (pun intended) price for our radios/bikes. We should get premium service from the other guys in these regards).
Finally, the thing that troubles me most is not that a new software system has problems…but rather, that after a year the company that marketed the software seems to have made no headway in bringing the system nearer maturation. In fact, it almost seems we users have lost ground, with a new fault or two introduced for every one corrected. (I realize some people have few issues. I suspect this is because they don't get into functional areas that are problematic.)
It's a cool system. I just wish it didn't have all these nitnoid problems.
Alan
I was a programmer for a number of years. I even had my own software company. I have supervised software engineers, including hiring them… I have some software background, in other words.
I have a premium 6.5 GT Infotainment radio on my 2014 SG. Earlier, I had a 4.3 model.
Today, I was pulled over for an inspection by LEOs. No issues, but when I started up to pull away, I didn't want my stereo to come on blasting. (No matter where I leave the volume set at shutdown, the radio seems to come on after being off a while at a fairly loud volume).
So as the bike's firing up and the graphic starts on the radio screen, I'm pushing the volume toggle down repeatedly to try and catch the volume as quick as I can, and turn it down, as the radio boots up…
The radio not only turned the volume down…it went into a mode where I had NO volume control any longer. Pushing up…or down…on the volume toggle had no effect. I had to cycle the radio off/on to restore the volume function.
After I got home (I was headed home, from work when this happened), it occurred to me this kind of failure…where the user causes a problem by doing something you (the programmer) didn't plan for or expect them to do…is reminiscent of my experience with 'junior' programmers of other systems.
Namely, as a programmer you spend a good deal of your time protecting software with which humans interact directly, from erroneous inputs, limiting what a user can actually do to mess you (the software) up. Example: Me pressing the volume toggle down a jillion times shouldn't have resulted in a system failure…my 'extra' presses should have been ignored. ...And the software of a good programmer would have handled the event in stride.
The software in my 6.5 system has a lot of 'holes' in it. Like this one. Rather than stopping acting upon my inputs once I got to 'zero' volume, the software appears to have allowed my excessive 'down' toggles, processed them, and subsequently went into some weird state as a result…probably what's called an 'unhandled exception'.
This is the type of software snafu 'new' and inexperienced programmers are famous for. (My presumption is the people who are writing the software for our systems are qualified to do so, by education, etc., but that they don't have a great deal of experience…versus that the programmers are simply incompetent.)
A small software enterprise is particularly susceptible to this type of thing, i.e., assigning a new project to a 'green' programmer. Because they're essentially short-handed. There are no real 'trainees' in such an outfit. (New Guy will work for less money than Seasoned Guy, BTW--an inducement to a small shop to hire New Guy versus Senior Guy).
The control software for our systems is not a major undertaking. It's the type of software project that would be a challenge for a new person with a solid education, but would certainly not be beyond them. But what you'll see…what we're seeing in fact, I believe…is a control system written by a newbie, a system that works well about 90% of the time…but that is as 'buggy' as a flop-house mattress, when you get down to the fine-points.
So that's my theory. That's why we're seeing the issues we're seeing. Some things are one-time occurrences (because the sequence of events that produce them--like my toggle-strokes today--don't occur frequently). Some things happen frequently--like the auto-dimming function (or so it seems to be this function) keeping the screen brightness at a bare minimum such that you can't see anything on the radio screen, for about 10 minutes after power up.
If you're still with me, thanks. Now to the point. None of us should accept this situation. I am making a list of my radio's faults, and taking them to the dealer with the expectation that they'll be fixed under warranty. I urge those of you who are experiencing problems to be proactive as well. Rather than wait for fixes (which might never come), I encourage you to do what I'm doing, and make your faults known to the dealers. They, in turn, can pass these on to the MoCo…who can present the 'bug reports' to the contractor who's produced this fine piece of software. (I don't think we should cut them, or the MoCo any slack. We were charged a 'premium' (pun intended) price for our radios/bikes. We should get premium service from the other guys in these regards).
Finally, the thing that troubles me most is not that a new software system has problems…but rather, that after a year the company that marketed the software seems to have made no headway in bringing the system nearer maturation. In fact, it almost seems we users have lost ground, with a new fault or two introduced for every one corrected. (I realize some people have few issues. I suspect this is because they don't get into functional areas that are problematic.)
It's a cool system. I just wish it didn't have all these nitnoid problems.
Alan
Last edited by AlanStansbery; 09-18-2014 at 08:04 PM.
#2
I've had the non-response issue happen to me about three times now. A friend of mine who also just purchased a new Rushmore told me that if you don't press the "Accept" button before driving away, then the volume control doesn't work. I don't remember if that happened to me or not, but it sounds plausible. But I do agree, the system is very buggy. Not too bad so far, but it's almost like dealing with an old computer that locks up randomly.
#3
This is long. Apologies. It's about the fewest words I could use, and convey the message properly… If you don't own a bike with a new Infotainment Boom Box! radio, this isn't for you, anyway…you're welcome to read it. But the focus is others, like myself, who own a '14 or '15 Rushmore model...
I was a programmer for a number of years. I even had my own software company. I have supervised software engineers, including hiring them… I have some software background, in other words.
I have a premium 6.5 GT Infotainment radio on my 2014 SG. Earlier, I had a 4.3 model.
Today, I was pulled over for an inspection by LEOs. No issues, but when I started up to pull away, I didn't want my stereo to come on blasting. (No matter where I leave the volume set at shutdown, the radio seems to come on after being off a while at a fairly loud volume).
So as the bike's firing up and the graphic starts on the radio screen, I'm pushing the volume toggle down repeatedly to try and catch the volume as quick as I can, and turn it down, as the radio boots up…
The radio not only turned the volume down…it went into a mode where I had NO volume control any longer. Pushing up…or down…on the volume toggle had no effect. I had to cycle the radio off/on to restore the volume function.
After I got home (I was headed home, from work when this happened), it occurred to me this kind of failure…where the user causes a problem by doing something you (the programmer) didn't plan for or expect them to do…is reminiscent of my experience with 'junior' programmers of other systems.
Namely, as a programmer you spend a good deal of your time protecting software with which humans interact directly, from erroneous inputs, limiting what a user can actually do to mess you (the software) up. Example: Me pressing the volume toggle down a jillion times shouldn't have resulted in a system failure…my 'extra' presses should have been ignored. ...And the software of a good programmer would have handled the event in stride.
The software in my 6.5 system has a lot of 'holes' in it. Like this one. Rather than stopping acting upon my inputs once I got to 'zero' volume, the software appears to have allowed my excessive 'down' toggles, processed them, and subsequently went into some weird state as a result…probably what's called an 'unhandled exception'.
This is the type of software snafu 'new' and inexperienced programmers are famous for. (My presumption is the people who are writing the software for our systems are qualified to do so, by education, etc., but that they don't have a great deal of experience…versus that the programmers are simply incompetent.)
A small software enterprise is particularly susceptible to this type of thing, i.e., assigning a new project to a 'green' programmer. Because they're essentially short-handed. There are no real 'trainees' in such an outfit. (New Guy will work for less money than Seasoned Guy, BTW--an inducement to a small shop to hire New Guy versus Senior Guy).
The control software for our systems is not a major undertaking. It's the type of software project that would be a challenge for a new person with a solid education, but would certainly not be beyond them. But what you'll see…what we're seeing in fact, I believe…is a control system written by a newbie, a system that works well about 90% of the time…but that is as 'buggy' as a flop-house mattress, when you get down to the fine-points.
So that's my theory. That's why we're seeing the issues we're seeing. Some things are one-time occurrences (because the sequence of events that produce them--like my toggle-strokes today--don't occur frequently). Some things happen frequently--like the auto-dimming function (or so it seems to be this function) keeping the screen brightness at a bare minimum such that you can't see anything on the radio screen, for about 10 minutes after power up.
If you're still with me, thanks. Now to the point. None of us should accept this situation. I am making a list of my radio's faults, and taking them to the dealer with the expectation that they'll be fixed under warranty. I urge those of you who are experiencing problems to be proactive as well. Rather than wait for fixes (which might never come), I encourage you to do what I'm doing, and make your faults known to the dealers. They, in turn, can pass these on to the MoCo…who can present the 'bug reports' to the contractor who's produced this fine piece of software. (I don't think we should cut them, or the MoCo any slack. We were charged a 'premium' (pun intended) price for our radios/bikes. We should get premium service from the other guys in these regards).
Finally, the thing that troubles me most is not that a new software system has problems…but rather, that after a year the company that marketed the software seems to have made no headway in bringing the system nearer maturation. In fact, it almost seems we users have lost ground, with a new fault or two introduced for every one corrected. (I realize some people have few issues. I suspect this is because they don't get into functional areas that are problematic.)
It's a cool system. I just wish it didn't have all these nitnoid problems.
Alan
I was a programmer for a number of years. I even had my own software company. I have supervised software engineers, including hiring them… I have some software background, in other words.
I have a premium 6.5 GT Infotainment radio on my 2014 SG. Earlier, I had a 4.3 model.
Today, I was pulled over for an inspection by LEOs. No issues, but when I started up to pull away, I didn't want my stereo to come on blasting. (No matter where I leave the volume set at shutdown, the radio seems to come on after being off a while at a fairly loud volume).
So as the bike's firing up and the graphic starts on the radio screen, I'm pushing the volume toggle down repeatedly to try and catch the volume as quick as I can, and turn it down, as the radio boots up…
The radio not only turned the volume down…it went into a mode where I had NO volume control any longer. Pushing up…or down…on the volume toggle had no effect. I had to cycle the radio off/on to restore the volume function.
After I got home (I was headed home, from work when this happened), it occurred to me this kind of failure…where the user causes a problem by doing something you (the programmer) didn't plan for or expect them to do…is reminiscent of my experience with 'junior' programmers of other systems.
Namely, as a programmer you spend a good deal of your time protecting software with which humans interact directly, from erroneous inputs, limiting what a user can actually do to mess you (the software) up. Example: Me pressing the volume toggle down a jillion times shouldn't have resulted in a system failure…my 'extra' presses should have been ignored. ...And the software of a good programmer would have handled the event in stride.
The software in my 6.5 system has a lot of 'holes' in it. Like this one. Rather than stopping acting upon my inputs once I got to 'zero' volume, the software appears to have allowed my excessive 'down' toggles, processed them, and subsequently went into some weird state as a result…probably what's called an 'unhandled exception'.
This is the type of software snafu 'new' and inexperienced programmers are famous for. (My presumption is the people who are writing the software for our systems are qualified to do so, by education, etc., but that they don't have a great deal of experience…versus that the programmers are simply incompetent.)
A small software enterprise is particularly susceptible to this type of thing, i.e., assigning a new project to a 'green' programmer. Because they're essentially short-handed. There are no real 'trainees' in such an outfit. (New Guy will work for less money than Seasoned Guy, BTW--an inducement to a small shop to hire New Guy versus Senior Guy).
The control software for our systems is not a major undertaking. It's the type of software project that would be a challenge for a new person with a solid education, but would certainly not be beyond them. But what you'll see…what we're seeing in fact, I believe…is a control system written by a newbie, a system that works well about 90% of the time…but that is as 'buggy' as a flop-house mattress, when you get down to the fine-points.
So that's my theory. That's why we're seeing the issues we're seeing. Some things are one-time occurrences (because the sequence of events that produce them--like my toggle-strokes today--don't occur frequently). Some things happen frequently--like the auto-dimming function (or so it seems to be this function) keeping the screen brightness at a bare minimum such that you can't see anything on the radio screen, for about 10 minutes after power up.
If you're still with me, thanks. Now to the point. None of us should accept this situation. I am making a list of my radio's faults, and taking them to the dealer with the expectation that they'll be fixed under warranty. I urge those of you who are experiencing problems to be proactive as well. Rather than wait for fixes (which might never come), I encourage you to do what I'm doing, and make your faults known to the dealers. They, in turn, can pass these on to the MoCo…who can present the 'bug reports' to the contractor who's produced this fine piece of software. (I don't think we should cut them, or the MoCo any slack. We were charged a 'premium' (pun intended) price for our radios/bikes. We should get premium service from the other guys in these regards).
Finally, the thing that troubles me most is not that a new software system has problems…but rather, that after a year the company that marketed the software seems to have made no headway in bringing the system nearer maturation. In fact, it almost seems we users have lost ground, with a new fault or two introduced for every one corrected. (I realize some people have few issues. I suspect this is because they don't get into functional areas that are problematic.)
It's a cool system. I just wish it didn't have all these nitnoid problems.
Alan
My system has been perfect so far.
#4
#5
Hopefully that happened in your incident.
#6
Great write-up/observation....
However, as a programmer, i would challenge any software to work as someone might have envisioned from the start...and the radio (and its software) is just part of a vast array of parts that were changed for the Rushmore line when released.
I am a filmmaker by trade and have been using the same editing software since 2002. Even though it is a very powerful editing suite, there are still bugs in the code that makes it do strange things to this day....even after having several hundreds(possibly more) of people alpha and beta test... (we are at Version 12 build 720)....
it will come around...
However, as a programmer, i would challenge any software to work as someone might have envisioned from the start...and the radio (and its software) is just part of a vast array of parts that were changed for the Rushmore line when released.
I am a filmmaker by trade and have been using the same editing software since 2002. Even though it is a very powerful editing suite, there are still bugs in the code that makes it do strange things to this day....even after having several hundreds(possibly more) of people alpha and beta test... (we are at Version 12 build 720)....
it will come around...
#7
Trending Topics
#8
Pretty cool assessment of the issues.. I hope that the absence of the software update on
H-D.com means they are actively addressing the bugs and properly testing the system. I agree problems are normal but after a year the basic issues should have been corrected.
Maybe they need to go open source and let some talented programmers show what the system can do.
H-D.com means they are actively addressing the bugs and properly testing the system. I agree problems are normal but after a year the basic issues should have been corrected.
Maybe they need to go open source and let some talented programmers show what the system can do.
#10
I'm actually to the point where when I crank my bike I'm not wondering "IF" my Infotainment is going to "act up". I'm now wondering "which" glitch am I going to see this time. It's usually the dark screen syndrome but now I can't even get my background color to change anymore. Not that the background color is a big deal but hey, I'm supposed to be able to do that!!!!