Seriously, the story of the space program is not "we did so well nothing went wrong" but, "when things went wrong we used our guts and brains and fixed them"
Examples:
Gemini 8 thruster stuck. Armstrong was able to regain control and return safely home. Apollo 11 landing 1201 and 1202 program alarms. Programmers on the ground and flight engineers were able to rapidly determine that the alarms posed no threat and the landing continued to success. Apollo 13. Catastrophic explosion disabled the service module. The astronauts returned home safely using the LEM as a lifeboat and some creative navigation. Skylab launch: Ripped off a solar panel and part of the outer skin. Astronauts were able to rig a replacement screen to cool inside of the lab and open the other solar panel that was stuck partly open. Three expeditions extended the time in space records and recorded what was then the most detail solar observations ever. STS-49: Multiple attempts to capture and return an Intelsat satellite failed, but a final attempt involving the shuttle commander flying directly to the satellite and it being hand-captured by 3 spacewalkers succeeded.
There are plenty more, including the recent working solving problems with stuck and torn solar panels.
Incidentally, these kinds of things are why I favor human spaceflight over robots for complex and difficult challenges.
This is a coding error. A subtle, non-obvious one perhaps, but a bug nevertheless. Not *that* subtle, for those of us who know what we are doing. Yet let's look at the article:
We looked through the code on paper, literally line by line, and just couldn't for the life of us imagine what the problem was. It couldn't be the list of obstacles: right there was the line where the old obstacles got deleted. Sitting in a McDonald's the night before the competition, we still didn't know why the computer kept dying a slow death. Because we didn't know why this problem kept appearing at 40 minutes, we decided to set a timer. After 40 minutes, we would stop the car and reboot the computer to restore the performance. I read that and I say "scrubs". Rebooting is a NASTY HACK. Pardon me for a little bitterness but I've seen this over and over in embedded systems by hardware types trying to be programmers, even from such prestigious places as Princeton. Some brilliant hardware guys will devalue the software driving (bad pun haha) the thing that it gets slapped on as a low-priority task to be done "after the hardware works". It's not helped by the occasions when, for example, a signal processing whiz is too impatient to work with a programmer without the same background to spec out software for cylindrical patch antenna tools.
I had my iPhone at the ready and it was quite capable of opening the document. I was able to answer her question immediately and it made me look like I was really on top of things. I guess that makes me "insane." Well, not necessarily insane, but, when is the last time you took a vacation?
As for convergence, I'm against half-baked cheapo versions of things that I depend on. Phones should let me talk to people without crappy signals and dropped calls. PDAs should be easy to get appointments, addresses, notes, and reminders into and out of as quickly and easily as paper. A camera should take nice photographs, not 320x240 pixelated postage stamps. A laptop should be able to run all the apps I'd run on my desktop machine, though I'll allow reduced performance in exchange for portability. As of today, and for oh, I'll stick my neck out and say for another decade, no all-in-one device can manage all that adequately.
OK, we know there are bugs in *this* version of , but we promise in out next revision we'll fix them, plus new features, and stuff that will make the version you have not work with it. It'll only cost you an arm and a leg to upgrade, or you can let us suck blood out of you on a regular basis via our subscription support program and get the next version at a nominal discount.
While we're at it, we won't mention that upgrading to our newest version will break your other important software from our competitors, but we'll sell you support to migrate those functions to our software.
There's a whole sub-specialty of drug interactions research and outcomes looking for treatments contraindicated in certain cases. Part of the process of getting a new treatment approved is ensuring that any interactions are known are avoidable or treatable. Consider what the technology industry would be like if every new product or piece of software had to go through the same kind of testing for possible undesirable side effects and had to document them all. Remember Windows 3.1 and 95 vs. DR-DOS? Well, after putting out a product that would break healthy software, the vendor had a solution for you -- at a price.
At the risk of being modded 'redundant', I have to point out that software and hardware companies don't exactly have best track record of putting out working systems vs. creating a market of ongoing charges to patch and pamper the broken ones they do put out.
Once the profit motive and shareholder ROI enters the picture, it's easy to find commonality across the two fields.
If someone actually wrote software that works, they wouldn't make billions selling consulting and support hours to install/troubleshoot/upgrade/recover/configure/patch the problems.
n the future you will have a magic gizmo that can take a look inside your body and synthesize a drug for your needs and it would mean that you have access to technology that is now possessed only by big pharma. As long as your magic gizmo can check in with the license server every time it needs to dispense a drug, and doesn't get accidentally marked as an illegal pirated copy of the gizmo and shut down. On top of that, better hope that the gizmo's makers don't force a patch update on it that causes it to go crazy and produce 10 times the dosage you need, plus another drug that supposed to be good for you but actually makes your heartrate climb towards 200bpm.
I can hardly imagine what the medical profession would be like had it been subjected to the so-called progress and innovation we've been cursed with in the tech industry in the past couple of decades, but the possibilities are horrifying. Microsoft Doctor? Intel Inside? Intestinal Exploder? "rights management" for your medications? Nursing outsourced to call centers? No thanks, Andy.
Yep. Programmers should know how to spell correctly in their native language. But hey, all through school those technonerds where likely the same ones who never missed a chance to whine about how they hated their English (or whatever) classes and thought that learning grammar and spelling were a waste of time when they could be doing cool geek stuff. The rise 1337-speak and txtspeak hasn't helped.
At least in the real writing business there are editors trained and paid to catch these errors.
Being unable to spell correctly makes you look really stupid to most people.
Just FYI, if you have a decent programming environment, it should at least flag cases where you've mistyped an existing identifier. If there's an ImmediateFlag in your code, you'd get a warning if you typed ImediateFlag or ImmediateFalg or whatever. Not much help when the programmer is creating new identifiers, of course. Although I've seen cases where the programmer in question for whatever reason decided that because ImediateFlag was undefined then they would just define it, even though ImmediateFlag existed and was what they meant. That ought to get you fired in my book.
Hey by the way, pair programming is a great way to have continuous code reviews and a check on some of the more typical fumble-finger errors.
Well, aside from what the other reply pointed out about the IDEs you clearly have missed in your exploration, I gather that what you really want is VB6 for Linux?
There's really only a few numbers you need to be concerned about.
* How many people is the bean counter going to cut from your department?
* How much is the bean counter going to cut your department's budget?
* How many weeks until your job is eliminated?
The final number to be concerned about is: What's the going rate for ex-F150 sysadmins?
It seems *companies* that release a version of or part of their software as open source seem to have an aversion to using existing licenses. Too many of them take a common license, and then just change the name. This is also true for open-source foundations that are arms of the various companies. Consider:
* Apache Software License
* Apache License, 2.0
* Apple Public Source License
* Computer Associates Trusted Open Source License 1.1
* Eclipse Public License
* IBM Public License
* Intel Open Source License
* Jabber Open Source License
* Lucent Public License Version 1.02
* Mozilla Public License 1.1 (MPL)
* Qt Public License (QPL)
* RealNetworks Public Source License V1.0
* Sun Public License
* Zope Public License
And that list is selection from *just* the OSI-approved ones, never mind the rest of them touted as open but not approved. Is it the lawyers or marketing that drives this idea of taking a perfectly good license, making minor customizations, and stamping it with a brand name?
A properly trained, incentivized and provisioned Java team can run rings around a Perl team in terms of working code produced, as well as (more importantly) cost to develop and cost to maintain. and a python team can do it in half the time, and half the code.
And the LISP team already did it, back in the 60s.
Quite frankly, it's probably time to be looking around for new job. When what should be technical decisions get made that far up the chain then they are invulnerable to feedback from the "hands on the keyboard" types. The time-frames and the financial considerations are all too far out of touch with operations for technical issues to come into play, and any attempt by anyone below senior management's direct reports to second-guess the costs will be treated with bemused patronization. In fact, put a note on your calendar for say, one year from now, or whatever the time frame for the "standardization" steamroller is planned. Whether you are with the company or not, check back and see if any change of direction has occurred. Post to/. about it.
"vendors like Microsoft provide a roadmap for the future."
Clearly the article CIO misspoke. What he meant to say was,
"sales and marketing departments of vendors like Microsoft promise they will include the features and bug fixes we want in the next version. We're stupid enough or paid off well enough to believe that this time they really will. All the previous times in the past when the new version didn't fix or add anything but incompatibilities with what we have, we pretend didn't happen. When open source projects tell us that a something we want is prohibitively expensive, violates licensing, or can't be completed in the time we want, we just say they are whining little primadonna programmers who could be replaced by my cousin's kid who has a VB cert from ITT Tech."
Sure, there are many examples, however I will tell you that there's little or no universal agreement. For example, I know some folks that consider qmail to be a terrific program, at least in design and coding, but there are plenty of criticism of qmail.
I suggest getting a copy of Code Reading: The Open Source Perspective by Diomidis Spinellis. He at least will introduce readers to a number of different criteria by which code can be judged.
if you like being hired for those sort of positions where they offer you $500 and a couple of weeks to build a cross-platform (windows 95 AND 98!) ACID multi-user threadsafe networked content management and document control system.
Slashdot Mirror
Seriously, the story of the space program is not "we did so well nothing went wrong" but, "when things went wrong we used our guts and brains and fixed them"
Examples:
Gemini 8 thruster stuck. Armstrong was able to regain control and return safely home.
Apollo 11 landing 1201 and 1202 program alarms. Programmers on the ground and flight engineers were able to rapidly determine that the alarms posed no threat and the landing continued to success.
Apollo 13. Catastrophic explosion disabled the service module. The astronauts returned home safely using the LEM as a lifeboat and some creative navigation.
Skylab launch: Ripped off a solar panel and part of the outer skin. Astronauts were able to rig a replacement screen to cool inside of the lab and open the other solar panel that was stuck partly open. Three expeditions extended the time in space records and recorded what was then the most detail solar observations ever.
STS-49: Multiple attempts to capture and return an Intelsat satellite failed, but a final attempt involving the shuttle commander flying directly to the satellite and it being hand-captured by 3 spacewalkers succeeded.
There are plenty more, including the recent working solving problems with stuck and torn solar panels.
Incidentally, these kinds of things are why I favor human spaceflight over robots for complex and difficult challenges.
unless he's doing a certain class of numeric problems, I think you mean "discreet"
Old mines have a nasty tendency to flood, or at least slowly get a few inches of water over the years from seepage.
As for convergence, I'm against half-baked cheapo versions of things that I depend on. Phones should let me talk to people without crappy signals and dropped calls. PDAs should be easy to get appointments, addresses, notes, and reminders into and out of as quickly and easily as paper. A camera should take nice photographs, not 320x240 pixelated postage stamps. A laptop should be able to run all the apps I'd run on my desktop machine, though I'll allow reduced performance in exchange for portability. As of today, and for oh, I'll stick my neck out and say for another decade, no all-in-one device can manage all that adequately.
Yep, keep 'em hooked all right.
OK, we know there are bugs in *this* version of , but we promise in out next revision we'll fix them, plus new features, and stuff that will make the version you have not work with it. It'll only cost you an arm and a leg to upgrade, or you can let us suck blood out of you on a regular basis via our subscription support program and get the next version at a nominal discount.
While we're at it, we won't mention that upgrading to our newest version will break your other important software from our competitors, but we'll sell you support to migrate those functions to our software.
There's a whole sub-specialty of drug interactions research and outcomes looking for treatments contraindicated in certain cases. Part of the process of getting a new treatment approved is ensuring that any interactions are known are avoidable or treatable. Consider what the technology industry would be like if every new product or piece of software had to go through the same kind of testing for possible undesirable side effects and had to document them all. Remember Windows 3.1 and 95 vs. DR-DOS? Well, after putting out a product that would break healthy software, the vendor had a solution for you -- at a price.
Same song, different key.
Once the profit motive and shareholder ROI enters the picture, it's easy to find commonality across the two fields.
If someone actually wrote software that works, they wouldn't make billions selling consulting and support hours to install/troubleshoot/upgrade/recover/configure/patch the problems.
Fixed for you.
I can hardly imagine what the medical profession would be like had it been subjected to the so-called progress and innovation we've been cursed with in the tech industry in the past couple of decades, but the possibilities are horrifying. Microsoft Doctor? Intel Inside? Intestinal Exploder? "rights management" for your medications? Nursing outsourced to call centers? No thanks, Andy.
SAP and PeopleSoft == ENTERPRISEY!!
Along with Procedural Programming, this could REVOLUTIONIZE the software industry!!
Yep. Programmers should know how to spell correctly in their native language. But hey, all through school those technonerds where likely the same ones who never missed a chance to whine about how they hated their English (or whatever) classes and thought that learning grammar and spelling were a waste of time when they could be doing cool geek stuff. The rise 1337-speak and txtspeak hasn't helped.
At least in the real writing business there are editors trained and paid to catch these errors.
Being unable to spell correctly makes you look really stupid to most people.
Just FYI, if you have a decent programming environment, it should at least flag cases where you've mistyped an existing identifier. If there's an ImmediateFlag in your code, you'd get a warning if you typed ImediateFlag or ImmediateFalg or whatever. Not much help when the programmer is creating new identifiers, of course. Although I've seen cases where the programmer in question for whatever reason decided that because ImediateFlag was undefined then they would just define it, even though ImmediateFlag existed and was what they meant. That ought to get you fired in my book.
Hey by the way, pair programming is a great way to have continuous code reviews and a check on some of the more typical fumble-finger errors.
Comprehensive, well-written documentation. ... that would be out-of-date the moment it's published, if not before?
I take it you're a VB6 developer?
Well, aside from what the other reply pointed out about the IDEs you clearly have missed in your exploration, I gather that what you really want is VB6 for Linux?
So, you want it to cater to VB programmers?
There's really only a few numbers you need to be concerned about.
* How many people is the bean counter going to cut from your department?
* How much is the bean counter going to cut your department's budget?
* How many weeks until your job is eliminated?
The final number to be concerned about is: What's the going rate for ex-F150 sysadmins?
It seems *companies* that release a version of or part of their software as open source seem to have an aversion to using existing licenses. Too many of them take a common license, and then just change the name. This is also true for open-source foundations that are arms of the various companies. Consider:
* Apache Software License
* Apache License, 2.0
* Apple Public Source License
* Computer Associates Trusted Open Source License 1.1
* Eclipse Public License
* IBM Public License
* Intel Open Source License
* Jabber Open Source License
* Lucent Public License Version 1.02
* Mozilla Public License 1.1 (MPL)
* Qt Public License (QPL)
* RealNetworks Public Source License V1.0
* Sun Public License
* Zope Public License
And that list is selection from *just* the OSI-approved ones, never mind the rest of them touted as open but not approved. Is it the lawyers or marketing that drives this idea of taking a perfectly good license, making minor customizations, and stamping it with a brand name?
A properly trained, incentivized and provisioned Java team can run rings around a Perl team in terms of working code produced, as well as (more importantly) cost to develop and cost to maintain. and a python team can do it in half the time, and half the code.
And the LISP team already did it, back in the 60s.
You used the non-word "incentivized". You fail.
Quite frankly, it's probably time to be looking around for new job. When what should be technical decisions get made that far up the chain then they are invulnerable to feedback from the "hands on the keyboard" types. The time-frames and the financial considerations are all too far out of touch with operations for technical issues to come into play, and any attempt by anyone below senior management's direct reports to second-guess the costs will be treated with bemused patronization. In fact, put a note on your calendar for say, one year from now, or whatever the time frame for the "standardization" steamroller is planned. Whether you are with the company or not, check back and see if any change of direction has occurred. Post to /. about it.
"vendors like Microsoft provide a roadmap for the future."
Clearly the article CIO misspoke. What he meant to say was,
"sales and marketing departments of vendors like Microsoft promise they will include the features and bug fixes we want in the next version. We're stupid enough or paid off well enough to believe that this time they really will. All the previous times in the past when the new version didn't fix or add anything but incompatibilities with what we have, we pretend didn't happen. When open source projects tell us that a something we want is prohibitively expensive, violates licensing, or can't be completed in the time we want, we just say they are whining little primadonna programmers who could be replaced by my cousin's kid who has a VB cert from ITT Tech."
Sure, there are many examples, however I will tell you that there's little or no universal agreement. For example, I know some folks that consider qmail to be a terrific program, at least in design and coding, but there are plenty of criticism of qmail.
I suggest getting a copy of Code Reading: The Open Source Perspective by Diomidis Spinellis. He at least will introduce readers to a number of different criteria by which code can be judged.
if you like being hired for those sort of positions where they offer you $500 and a couple of weeks to build a cross-platform (windows 95 AND 98!) ACID multi-user threadsafe networked content management and document control system.