Slack - Getting Past Burnout, Busywork and ....
on
Working Hard?
·
· Score: 1
Slashdot had a review of a book by Tom Demarco called "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency". The Slashdot review is here. The author makes several excellent points, which all tie into the idea that you can only work so much before productivity, flexibility and creativity have diminished to the point where its not worth putting in more hours. It's amazing how many managers out there don't have this message...
Well, I agree about how the post-launch Columbia decision was handled, but I have to disagree on all the others.
Anything worth doing has some risk involved, and while engineers and scientists will strive to reduced those risks as much as possible, they cannot be eliminated entirely. NASA is made of of human beings, not perfect automatons whose godlike prowess and forsight eschew all possibility of failure. They're people, flesh and blood, they have families and hopes and dreams, just like the rest of us. And they make mistakes, sometimes boneheaded mistakes, just like the rest of us. Judge as harshly as *you* would like to be judged...
One of my physics professors told me once that if you do not fail everyone once in a while, you are not really pushing the limits of your capabilities. Do I want NASA to play it safe and do the easy things, or do I want NASA to push the envelope and be a driver for new technologies? For the money being spent, I want the latter.
Moving the smarmy comments of Tang and pens aside, I think many miss the point about what NASA is for. NASA is about expanding our body of knowledge: about our world, our universe and about ourselves. The lessons of the Challenger accident have served as a cautionary tale for risk-managers in all industries (I had a case study on it in a Financial and Managerial Accounting class last fall, or all places). I'm sure the Columbia accident will bring some new insights as well.
It is naive to think that diverting the budget of NASA somewhere else is going to eliminate war and famine. Those things are caused by greed and malice in the human soul, and cannot be healed by adding money.
I recently had to contact AOL regarding mailing list delivery for one of our clients. The list is totally legit, with email confirmation (open+confirm) required before the person can be added to the list. Anyway, he subscribed to AOL, then subscribed to the list in an effort to see whether his list was being filtered after several list subscribers complained. Lo and Behold! The list was being filtered!
So I called, and after a week of runaround trying different things, they informed me that the list must be filtered because more that 10% of the recipients are invalid. When a list has more that 10% bad email addresses for @aol, @netscape and any other AOL controlled domains, any deliveries from that list to AOL mail exchangers is dumped entirely. No bounces back to the mail server, or a notice to postmaster to explain why the messages were dropped. Just silence.
The only way to find out which of the people on the list are still valid is to send each one an email manually (ie: not delivered in bulk), and see if it bounces. This is a major pain in the neck for a list with over 2000+ AOL addresses on it.
Oh, and that phone number that I called about the problem? It now dumps to a voice mailbox which is full. Which is fine because when it wasn't full, nobody answered it anyway.
I've used Boa in a number of cases where certain groups of CGI scripts need to run as a specific UID and I didn't want to use the SUID functionality of Apache. Because it is so lightweight, having a few of these hanging around for various citical system UIDs can really be handy, esp. if you have an aversion to using SUID wrappers and such. A good example is using Boa running as the same UID as the mailing list processor so you can have web administration of the list rosters. And the users don't even know about it because I use the ProxyPass directive to shuttle the requests from the standard port 80 up to the port on which Boa is running, so my logging is still centralized/standardized through Apache.
I have to agree with several of the other posts. You really need to hire a security competent network administrator, AND have third party audits. If the audits don't pass, perhaps you don't have the right person in the job.
Rotate between auditing companies, discarding the ones that don't give you the level of service you need until you have three that you can count on.
There are a number of "managed internet security" companies out there that can provide the expertise if you can't hire it internally. One of them is SecurePipe. They do provide a range of internet security services, including audits and managed firewall products.
Slashdot Mirror
Slashdot had a review of a book by Tom Demarco called "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency". The Slashdot review is here. The author makes several excellent points, which all tie into the idea that you can only work so much before productivity, flexibility and creativity have diminished to the point where its not worth putting in more hours. It's amazing how many managers out there don't have this message...
Well, I agree about how the post-launch Columbia decision was handled, but I have to disagree on all the others.
Anything worth doing has some risk involved, and while engineers and scientists will strive to reduced those risks as much as possible, they cannot be eliminated entirely. NASA is made of of human beings, not perfect automatons whose godlike prowess and forsight eschew all possibility of failure. They're people, flesh and blood, they have families and hopes and dreams, just like the rest of us. And they make mistakes, sometimes boneheaded mistakes, just like the rest of us. Judge as harshly as *you* would like to be judged...
One of my physics professors told me once that if you do not fail everyone once in a while, you are not really pushing the limits of your capabilities. Do I want NASA to play it safe and do the easy things, or do I want NASA to push the envelope and be a driver for new technologies? For the money being spent, I want the latter.
Moving the smarmy comments of Tang and pens aside, I think many miss the point about what NASA is for. NASA is about expanding our body of knowledge: about our world, our universe and about ourselves. The lessons of the Challenger accident have served as a cautionary tale for risk-managers in all industries (I had a case study on it in a Financial and Managerial Accounting class last fall, or all places). I'm sure the Columbia accident will bring some new insights as well.
It is naive to think that diverting the budget of NASA somewhere else is going to eliminate war and famine. Those things are caused by greed and malice in the human soul, and cannot be healed by adding money.
So I called, and after a week of runaround trying different things, they informed me that the list must be filtered because more that 10% of the recipients are invalid. When a list has more that 10% bad email addresses for @aol, @netscape and any other AOL controlled domains, any deliveries from that list to AOL mail exchangers is dumped entirely. No bounces back to the mail server, or a notice to postmaster to explain why the messages were dropped. Just silence.
The only way to find out which of the people on the list are still valid is to send each one an email manually (ie: not delivered in bulk), and see if it bounces. This is a major pain in the neck for a list with over 2000+ AOL addresses on it.
Oh, and that phone number that I called about the problem? It now dumps to a voice mailbox which is full. Which is fine because when it wasn't full, nobody answered it anyway.
I've used Boa in a number of cases where certain groups of CGI scripts need to run as a specific UID and I didn't want to use the SUID functionality of Apache. Because it is so lightweight, having a few of these hanging around for various citical system UIDs can really be handy, esp. if you have an aversion to using SUID wrappers and such. A good example is using Boa running as the same UID as the mailing list processor so you can have web administration of the list rosters. And the users don't even know about it because I use the ProxyPass directive to shuttle the requests from the standard port 80 up to the port on which Boa is running, so my logging is still centralized/standardized through Apache.
Boa is very cool. Kudos to the developers!
I have to agree with several of the other posts. You really need to hire a security competent network administrator, AND have third party audits. If the audits don't pass, perhaps you don't have the right person in the job.
Rotate between auditing companies, discarding the ones that don't give you the level of service you need until you have three that you can count on.
There are a number of "managed internet security" companies out there that can provide the expertise if you can't hire it internally. One of them is SecurePipe. They do provide a range of internet security services, including audits and managed firewall products.