When you are working with big customers in the Avionics Industry, they tend to understand that turnabout takes time. We all have to deal with process our companies have created to comply with DO178-B. This process is comparable to the ISO 9000 family. So when you tell a customer it will take 2 weeks to fix a known set of issues, that is generally accepted. If you have an engineer on the scene, the turnabout is more in the scope of days, with the official patch coming a week after the issues are worked out.
I work for a SMB which supplies a certain European company with equipment.
All issues reported are critical and must be fixed now type of issues. Initially we supplied uncontrolled development builds 1-2 times a week, after receiving bug reports by email. Realization of our mistake occurred when we started receiving bug reports for versions of software that were reported officially for uncontrolled software. Bug tracking and resolution at this point because a nightmare. Ultimately it was agreed upon that all "patch" releases had to be somewhat formal, some formal testing, minimum 2 week turnaround. So now every time a milestone release is pushed back because of unrealistic "marketing" / "program management" decisions they get a new "patch" release.
A fast turnabout to a customer without having an integration person on site to manage customer expectations is asking for trouble. Now generally before milestone releases we send a person over to run informal tests in their lab. He reports results of the test, we supply our engineer with a new development build. New informal tests are performed... (yes cyclical process). This way our engineer on the scene could help manage expectation and focus the customer on to what are the real must have issues.
This has proved the best model for us and the customer, mileage may vary.
I think this has more to do with Microsoft trying to gain the high ground by saying that we validate our input before passing it to third party applications. Where validating user input, really is a good thing is not always easy.
If Microsoft concedes that IE should validate/sanitize URL input before passing it to other applications, then other browsers should also validate/sanitize URL input before passing it to other vulnerable Microsoft/Adobe/IBM/... applications.
This just shows that the AdSense network is not robust enough to handle the amount of users that wanted to participate. By limiting the program to users that have high volume, they maximize profit. This allows that devision of Google to fund R&D on how to improve the network to include more participants. This just appears to be an issues of cost.
When you have to certify a computer to "Design level" as in DO178-B. You need to have the source code for the OS to be able to prove certain characteristics. What this does is remove the negotiation of the cost for the source from the equation. Though this means the company that uses the product will have to certify the OS themselves.
There are still a few industries in America that require "programming" be done by workers of American or "friendly" origins. Avionics and the defense are a good example of those industries. I assume that is were the next generation of Software Engineers will be trained.
Slashdot Mirror
Windows has replaced a very old UNIX platform on many US battle ships and apparently they are not alone. Windows for Warships
When you are working with big customers in the Avionics Industry, they tend to understand that turnabout takes time. We all have to deal with process our companies have created to comply with DO178-B. This process is comparable to the ISO 9000 family. So when you tell a customer it will take 2 weeks to fix a known set of issues, that is generally accepted. If you have an engineer on the scene, the turnabout is more in the scope of days, with the official patch coming a week after the issues are worked out.
I work for a SMB which supplies a certain European company with equipment.
... (yes cyclical process). This way our engineer on the scene could help manage expectation and focus the customer on to what are the real must have issues.
All issues reported are critical and must be fixed now type of issues. Initially we supplied uncontrolled development builds 1-2 times a week, after receiving bug reports by email. Realization of our mistake occurred when we started receiving bug reports for versions of software that were reported officially for uncontrolled software. Bug tracking and resolution at this point because a nightmare. Ultimately it was agreed upon that all "patch" releases had to be somewhat formal, some formal testing, minimum 2 week turnaround. So now every time a milestone release is pushed back because of unrealistic "marketing" / "program management" decisions they get a new "patch" release.
A fast turnabout to a customer without having an integration person on site to manage customer expectations is asking for trouble. Now generally before milestone releases we send a person over to run informal tests in their lab. He reports results of the test, we supply our engineer with a new development build. New informal tests are performed
This has proved the best model for us and the customer, mileage may vary.
I think this has more to do with Microsoft trying to gain the high ground by saying that we validate our input before passing it to third party applications. Where validating user input, really is a good thing is not always easy.
If Microsoft concedes that IE should validate/sanitize URL input before passing it to other applications, then other browsers should also validate/sanitize URL input before passing it to other vulnerable Microsoft/Adobe/IBM/... applications.
This just shows that the AdSense network is not robust enough to handle the amount of users that wanted to participate. By limiting the program to users that have high volume, they maximize profit. This allows that devision of Google to fund R&D on how to improve the network to include more participants. This just appears to be an issues of cost.
When you have to certify a computer to "Design level" as in DO178-B. You need to have the source code for the OS to be able to prove certain characteristics. What this does is remove the negotiation of the cost for the source from the equation. Though this means the company that uses the product will have to certify the OS themselves.
There are still a few industries in America that require "programming" be done by workers of American or "friendly" origins. Avionics and the defense are a good example of those industries. I assume that is were the next generation of Software Engineers will be trained.
mod +