I'm seriously tempted...
-
...to call out the makers of our forum software that we use for our support board here in public. This is not the first time I've got the feeling that important software that we rely on which has all the features we need that others don't have and took a lot of digging to find is supported by two guys in a basement who don't really give a damn any more. What happens? People make a little money and think they can retire? That customers have an infinite amount of patience for broken updates that weren't tested? That it's cool to tell someone who has been running a support board for a couple of years that they should simply wipe their database and start again and lose years of information and work rather than fixing a broken query in their latest update? Blaarghghgh!:mad: I've been tempted so many times to write our own asp.net forum software but every time I resist the urge, it's getting harder and harder.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
...to call out the makers of our forum software that we use for our support board here in public. This is not the first time I've got the feeling that important software that we rely on which has all the features we need that others don't have and took a lot of digging to find is supported by two guys in a basement who don't really give a damn any more. What happens? People make a little money and think they can retire? That customers have an infinite amount of patience for broken updates that weren't tested? That it's cool to tell someone who has been running a support board for a couple of years that they should simply wipe their database and start again and lose years of information and work rather than fixing a broken query in their latest update? Blaarghghgh!:mad: I've been tempted so many times to write our own asp.net forum software but every time I resist the urge, it's getting harder and harder.
"I don't want more choice. I just want better things!" - Edina Monsoon
*Pat on the shoulder* Hang in there old sport...
-Gatsby
-
...to call out the makers of our forum software that we use for our support board here in public. This is not the first time I've got the feeling that important software that we rely on which has all the features we need that others don't have and took a lot of digging to find is supported by two guys in a basement who don't really give a damn any more. What happens? People make a little money and think they can retire? That customers have an infinite amount of patience for broken updates that weren't tested? That it's cool to tell someone who has been running a support board for a couple of years that they should simply wipe their database and start again and lose years of information and work rather than fixing a broken query in their latest update? Blaarghghgh!:mad: I've been tempted so many times to write our own asp.net forum software but every time I resist the urge, it's getting harder and harder.
"I don't want more choice. I just want better things!" - Edina Monsoon
Do it. If they suck they wont care. If they don't suck and really care then maybe it will spur them to realize that just because they sell software that doe snot mean they are not held responsible for poor quality products. Personally I am getting sick of the mantra 'all software has bugs'. When was the last time an aircraft guidance system needed to be rebooted mid flight?
-
Do it. If they suck they wont care. If they don't suck and really care then maybe it will spur them to realize that just because they sell software that doe snot mean they are not held responsible for poor quality products. Personally I am getting sick of the mantra 'all software has bugs'. When was the last time an aircraft guidance system needed to be rebooted mid flight?
hehe hehe... He said
Ray Cassick wrote:
doe snot
-
Do it. If they suck they wont care. If they don't suck and really care then maybe it will spur them to realize that just because they sell software that doe snot mean they are not held responsible for poor quality products. Personally I am getting sick of the mantra 'all software has bugs'. When was the last time an aircraft guidance system needed to be rebooted mid flight?
Ray Cassick wrote:
When was the last time an aircraft guidance system needed to be rebooted mid flight?
I bet if that happened, the airline was United. I've been in a plane where after a 45 min delay we were told they were shutting off the plane to reboot the computer, and then we were good to go.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
...to call out the makers of our forum software that we use for our support board here in public. This is not the first time I've got the feeling that important software that we rely on which has all the features we need that others don't have and took a lot of digging to find is supported by two guys in a basement who don't really give a damn any more. What happens? People make a little money and think they can retire? That customers have an infinite amount of patience for broken updates that weren't tested? That it's cool to tell someone who has been running a support board for a couple of years that they should simply wipe their database and start again and lose years of information and work rather than fixing a broken query in their latest update? Blaarghghgh!:mad: I've been tempted so many times to write our own asp.net forum software but every time I resist the urge, it's getting harder and harder.
"I don't want more choice. I just want better things!" - Edina Monsoon
Three of my biggest clients are "rescue jobs" - where I have literally rescued their business from the clutches of their previous incompetenmt or (in one case) downright fraudulent software providers. Ditch them - and if it's not your decision, do what you can to make sure the people whose decision it is, do so. People (or companies) like that only get away with it as long as other people (or companies) let them. Fred
-
Do it. If they suck they wont care. If they don't suck and really care then maybe it will spur them to realize that just because they sell software that doe snot mean they are not held responsible for poor quality products. Personally I am getting sick of the mantra 'all software has bugs'. When was the last time an aircraft guidance system needed to be rebooted mid flight?
Ray Cassick wrote:
When was the last time an aircraft guidance system needed to be rebooted mid flight?
Different monster there, but then that is also why flight control software is often as much as 10 years behind in technology. You cannot move "new" things into flight systems rapidly without massive effort. Being "flight certified" is a rigorous process you do not even want to attempt. My software has been very lucky, it has never crashed during a live mission since it went out on first use. BUT, it has crashed outside of missions. I rely heavily on user-testing in some situations because it is impossible for me to ever see the data/environment being visualized, so I program off spec and send it out from spec. If that isn't a recipe for bugs, I don't know what is. But you also have to realize flight certification has risks too. If you make a change, any change, even 5 years ago, when a plane does crash, most recent changes are first suspect. When the holloman drone did a nose-dive into the desert, the first suspect was our software. It was the "new kid" on the block so to speak. We had to prove ourselves innocent before anything else could be examined. As it turned out, it was an Apollo 13 style error in hardware that was years old waiting for the right environment. It is true, you can never be rid of every possible bug. BUT that is no excuse to be lazy about them. Still, if you think CMMI level 5 is bad, try flight certifying software sometime.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
hehe hehe... He said
Ray Cassick wrote:
doe snot
-
Do it. If they suck they wont care. If they don't suck and really care then maybe it will spur them to realize that just because they sell software that doe snot mean they are not held responsible for poor quality products. Personally I am getting sick of the mantra 'all software has bugs'. When was the last time an aircraft guidance system needed to be rebooted mid flight?
Ray Cassick wrote:
Personally I am getting sick of the mantra 'all software has bugs'
Well technically it's true, it's what the producer of that software does about it that's the realy dividing line between good software and crappy software. Not caring about your customers is the kiss of death for software. I swear there is a lot of money to be made in simply replicating existing software from companies with known crappy support and a careless attitude about releases but supporting it properly and making damn sure a release is tested carefully.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
Ray Cassick wrote:
When was the last time an aircraft guidance system needed to be rebooted mid flight?
Different monster there, but then that is also why flight control software is often as much as 10 years behind in technology. You cannot move "new" things into flight systems rapidly without massive effort. Being "flight certified" is a rigorous process you do not even want to attempt. My software has been very lucky, it has never crashed during a live mission since it went out on first use. BUT, it has crashed outside of missions. I rely heavily on user-testing in some situations because it is impossible for me to ever see the data/environment being visualized, so I program off spec and send it out from spec. If that isn't a recipe for bugs, I don't know what is. But you also have to realize flight certification has risks too. If you make a change, any change, even 5 years ago, when a plane does crash, most recent changes are first suspect. When the holloman drone did a nose-dive into the desert, the first suspect was our software. It was the "new kid" on the block so to speak. We had to prove ourselves innocent before anything else could be examined. As it turned out, it was an Apollo 13 style error in hardware that was years old waiting for the right environment. It is true, you can never be rid of every possible bug. BUT that is no excuse to be lazy about them. Still, if you think CMMI level 5 is bad, try flight certifying software sometime.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I really do understand the state of things. I think that post developers (aside form a few) really DO care about their error rates. I just think it stinks when you talk to a company or a developer and they flip you this cavalier attitude about bugs. "who does not have bugs?" - "Everyone has SOME bugs..." - blah blah blah... Tons of people smoke crack too, that does not make it right. I know Windows has bugs, and I understand that a lot of them are in the parts that make Windows what it is, a customisable UI based OS. I have said it before, if Windows was made to run on one single processor using one single graphics system and one single sound system, and had none of the cool ways to make the OS 'yours' then it would be much more stable, but it would also have a much lower market share. This brings to mind platforms like SPARC and such... I just think that far too many developers just think it is OK to have a few bugs. I take bugs personally to be honest. They are a mistake that I made and reflect on me. I just think that with all the RAD tools that are available and the simplicity of setting up a web site to sell software, people loose site of what it means to be in business.
-
Ray Cassick wrote:
When was the last time an aircraft guidance system needed to be rebooted mid flight?
I bet if that happened, the airline was United. I've been in a plane where after a 45 min delay we were told they were shutting off the plane to reboot the computer, and then we were good to go.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Ray Cassick wrote:
Personally I am getting sick of the mantra 'all software has bugs'
Well technically it's true, it's what the producer of that software does about it that's the realy dividing line between good software and crappy software. Not caring about your customers is the kiss of death for software. I swear there is a lot of money to be made in simply replicating existing software from companies with known crappy support and a careless attitude about releases but supporting it properly and making damn sure a release is tested carefully.
"I don't want more choice. I just want better things!" - Edina Monsoon
John Cardinal wrote:
it's what the producer of that software does about it that's the really dividing line between good software and crappy software.
I agree. Two things that a SW company does that tick me off: 1) Argue with me that what I am seeing is a bug. Yeah, sometimes I try to use a feature in a way that was not intended, but tome that's still a bug because they LET me use it that way. I have had companies argue with me on this point even when 'my way' causes a crash and program bail. OK, I am doing something you did not intent to have work but guess what, I know know how to make your code crash and burn. At very least you need to NOT allow me to do that anymore. 2) Break something that WAS working by fixing something that was not. Has no one ever heard of regression testing?
-
John Cardinal wrote:
it's what the producer of that software does about it that's the really dividing line between good software and crappy software.
I agree. Two things that a SW company does that tick me off: 1) Argue with me that what I am seeing is a bug. Yeah, sometimes I try to use a feature in a way that was not intended, but tome that's still a bug because they LET me use it that way. I have had companies argue with me on this point even when 'my way' causes a crash and program bail. OK, I am doing something you did not intent to have work but guess what, I know know how to make your code crash and burn. At very least you need to NOT allow me to do that anymore. 2) Break something that WAS working by fixing something that was not. Has no one ever heard of regression testing?
Ray Cassick wrote:
At very least you need to NOT allow me to do that anymore.
Yeah, easily 90% of all the programming you do between the beta stage and release stage is firmly in the category of "I never guessed anyone would try to do that" or "What the hell?" :) Protecting users from themselves is critical but one of the most boring and uninspiring areas of work. Breaking something that was working is all too easy to do. It's really not possible to avoid this 100% of the time with a production project of substantial size and complexity. We have testing methods and standard scripts we run through but sometimes stuff gets missed. It's rare and only happened to me a handful of times in all the years I've been at this, but again, if someone reports it you *have* to fix it immediately and get the update out to everyone, not let it slide. A lot depends on the programmer who is doing the bug fix or feature change and their understanding of the effects that their changes could have, I think that too large a project with too many people leads to more of this kind of unintended consequences because people dont' have enough of the big picture to understand the consequences of what they're doing.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
Ray Cassick wrote:
At very least you need to NOT allow me to do that anymore.
Yeah, easily 90% of all the programming you do between the beta stage and release stage is firmly in the category of "I never guessed anyone would try to do that" or "What the hell?" :) Protecting users from themselves is critical but one of the most boring and uninspiring areas of work. Breaking something that was working is all too easy to do. It's really not possible to avoid this 100% of the time with a production project of substantial size and complexity. We have testing methods and standard scripts we run through but sometimes stuff gets missed. It's rare and only happened to me a handful of times in all the years I've been at this, but again, if someone reports it you *have* to fix it immediately and get the update out to everyone, not let it slide. A lot depends on the programmer who is doing the bug fix or feature change and their understanding of the effects that their changes could have, I think that too large a project with too many people leads to more of this kind of unintended consequences because people dont' have enough of the big picture to understand the consequences of what they're doing.
"I don't want more choice. I just want better things!" - Edina Monsoon
John Cardinal wrote:
I never guessed anyone would try to do that
You can sum it up like this: All software would work perfectly if it wasn't for those pesky users!!
------------------------------------------- Don't walk in front of me, I may not follow; Don't walk behind me, I may not lead; Just bugger off and leave me alone!!
-
I really do understand the state of things. I think that post developers (aside form a few) really DO care about their error rates. I just think it stinks when you talk to a company or a developer and they flip you this cavalier attitude about bugs. "who does not have bugs?" - "Everyone has SOME bugs..." - blah blah blah... Tons of people smoke crack too, that does not make it right. I know Windows has bugs, and I understand that a lot of them are in the parts that make Windows what it is, a customisable UI based OS. I have said it before, if Windows was made to run on one single processor using one single graphics system and one single sound system, and had none of the cool ways to make the OS 'yours' then it would be much more stable, but it would also have a much lower market share. This brings to mind platforms like SPARC and such... I just think that far too many developers just think it is OK to have a few bugs. I take bugs personally to be honest. They are a mistake that I made and reflect on me. I just think that with all the RAD tools that are available and the simplicity of setting up a web site to sell software, people loose site of what it means to be in business.
Ray Cassick wrote:
I just think that far too many developers just think it is OK to have a few bugs. I take bugs personally to be honest. They are a mistake that I made and reflect on me.
Same here, and I have pushed testing because my error rate has been lower than everyone else. They want to know why, I point to that, as well as other things. Automatic testing to human testing, I prefer to get sample data sets, or real datasets, or a simulator, or the equivalent. I have written simulators for spec-machines, and I have explained to the customer why it doesn't work. All language is interpretive, there are nuances that we believe mean one thing when they mean something else to another, also there are adaptions that are "forgotten" to be sent out to someone. If one person writes a simulator that all sides use, this is good. If someone needs a change the simulator is changed and sent out to everyone with the change, preferrably after a change request is done, and approvals, and notifications to the others the change is coming. But when they write a simulator based on the spec, and I write a simulator based on the spec, not only is there parallel development and wasted energies, but there is also the chance for reinterpretation on either side. That is where bugs can come from. If we both start from the same book, same data, same simululators, etc. then everyone can test on the same systems. Of course that doesn't stop someone from changing the live data at the last minute, but it does try to prevent it, or at least discourage it.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
John Cardinal wrote:
I never guessed anyone would try to do that
You can sum it up like this: All software would work perfectly if it wasn't for those pesky users!!
------------------------------------------- Don't walk in front of me, I may not follow; Don't walk behind me, I may not lead; Just bugger off and leave me alone!!
-
Ray Cassick wrote:
At very least you need to NOT allow me to do that anymore.
Yeah, easily 90% of all the programming you do between the beta stage and release stage is firmly in the category of "I never guessed anyone would try to do that" or "What the hell?" :) Protecting users from themselves is critical but one of the most boring and uninspiring areas of work. Breaking something that was working is all too easy to do. It's really not possible to avoid this 100% of the time with a production project of substantial size and complexity. We have testing methods and standard scripts we run through but sometimes stuff gets missed. It's rare and only happened to me a handful of times in all the years I've been at this, but again, if someone reports it you *have* to fix it immediately and get the update out to everyone, not let it slide. A lot depends on the programmer who is doing the bug fix or feature change and their understanding of the effects that their changes could have, I think that too large a project with too many people leads to more of this kind of unintended consequences because people dont' have enough of the big picture to understand the consequences of what they're doing.
"I don't want more choice. I just want better things!" - Edina Monsoon
John Cardinal wrote:
their understanding of the effects that their changes could have
This actually brings up a question about available tools. Do you think that there are good tools available to help developers get this bigger picture? Do you think just having a simple call graph that shows the tree of affected functions impacted by changing one is enough? Personally I think that this along with a good Unit testing package/system in place (and a decent design to start with) should be enough to fend off all but the real killer corner cases here.
-
Ray Cassick wrote:
When was the last time an aircraft guidance system needed to be rebooted mid flight?
I bet if that happened, the airline was United. I've been in a plane where after a 45 min delay we were told they were shutting off the plane to reboot the computer, and then we were good to go.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
were shutting off the plane to reboot the computer
One heck of a power switch on that computer. To restart, turn off airplane...:wtf:
-
Do it. If they suck they wont care. If they don't suck and really care then maybe it will spur them to realize that just because they sell software that doe snot mean they are not held responsible for poor quality products. Personally I am getting sick of the mantra 'all software has bugs'. When was the last time an aircraft guidance system needed to be rebooted mid flight?
-
John Cardinal wrote:
their understanding of the effects that their changes could have
This actually brings up a question about available tools. Do you think that there are good tools available to help developers get this bigger picture? Do you think just having a simple call graph that shows the tree of affected functions impacted by changing one is enough? Personally I think that this along with a good Unit testing package/system in place (and a decent design to start with) should be enough to fend off all but the real killer corner cases here.
No a call graph isn't enough, you have to *know* what goes where and what is affected by what. As for unit testing I don't believe in it and we don't use it. I believe it's a crutch designed for companies to be able to place far less trust in their developers and free them up to hire very large teams of low talent programmers in an effort to cheaply get software out the door faster. In other words factory programming. In our company we practice what I feel is artisan programming not factory programming, but we pick projects where we can be artisans so my opinion is obviously biased. In all the examples I've seen it used in it is used pointlessly in the great majority of methods / functions and is just a drain on resources and time and gives developers a false sense of security. So much important time seems to be wasted developing the tests, seeing if they are applicable, running the tests etc against a great majority of code that is blindingly simple and if coded correctly and defensively in the first place would not require a test at all under any circumstances. I do believe in something alternative which is special code that runs in debug builds only and make liberal use of that to ensure sanity checks etc where it makes sense in my own code.
"I don't want more choice. I just want better things!" - Edina Monsoon