"The problem with the interactions between health care pros and geeks has been the promise and failure of technology on many occasions to make our jobs better and easier...."
" I'm working with a patient bed now that incorporates a wide variety of features that makes it much more comfortable and ergonomic for both the patient and the nurse. And it works wonderfully - when it works. But some geek decided to put the controls, LCD panel, and circuit board in the bedrail - a bedrail that is slammed up and down all day and night as patients get in and out of bed, as they yank back and forth on it to adjust their position, and as staff pull on it to guide the bed down the hall to OR, CT, X-ray, etc. Pretty soon the bed either 'crashes', needing a reboot keypress that would cause an EMACS user to dislocate a phlange, or has a complete hardware failure. The bed dies."
Preach it, Alwin!
(Nice EMACS jab, that.)
I seem to be on the subject of economic fallacies today.
Scripting News: "And perhaps this series of notes on smoking cessation will help a couple of other people to quit before getting a deadly illness. So while it may seem grandiose to think of software as life-saving, it isn't really a huge stretch."
If someone throws a stone into a shop window, the owner needs to repair it. This puts people to work and increases total output. Since this creates jobs, would we be better off breaking lots of windows and repairing them?... This is the "broken window" fallacy...
No implied endorsement of the article; the last couple of paragraphs in particular may or may not be overstated. But interesting.
"I recently asked one of our developers to draw up a design for a specific component. After a few hours he returns telling me that he'd solved a very similar problem a previous place of employment and that they had developed a "neat" solution. The developer then became concerned that a ground-up re-implementation of these design patterns and principals may infringe on the other companies intellectual property or breach some copyright laws. This developer is talented and experienced that's why we hired him. The question is, at what point does 'drawing on experience' cross the line and invade others IP?"
The sad part is not the answer, but that the question needs to be asked. As one of the posts on Slashdot says, the answer depends on too many other variables to give a reasonable answer.
But before you get too upset, in general the answer is the engineer is mostly free to do as he wants for his new employer, with the exception of anything that may have been patented in his old solution, which happens to apply no matter what. Copyright is a null issue here as long as he doesn't pull old source code owned by the previous employer.
On that topic, I'm trying to build myself up a library of Python code that will be useful to me in the future, which I'll happily license to an employer in an unrestricted, but non-exclusive manner. The downside is I have to watch what I sign now; I can't afford a contract that tries to take ownership of everything I do, or worse, that I've ever done. You'd think the benefit of hours of programming not on their clock would be enough, but somewhere in their education, lawyers are apparently trained to ask for the moon, and not take anything less. (Been there. Didn't sign. Their loss.)
Yahoo Inc. announced today that it will debut a service that will let direct marketers send targeted e-mails to consumers based on their search engine activity.
...Only people with Yahoo e-mail accounts who have opted in to receive third-party offers will receive marketing e-mails based on their search activity.
Emphasis mine. It's yucky technology (yes, that's a technical term), but You Get What You Pay For sometimes. A bit of browser config might be able to block this, if you're careful about what sites let you set cookies.
|<- Future Posts||Past Posts ->|