Currently the total cost of the war in Iraq is about 500 billion dollars. I've often wondered what this war is worth in terms of opportunity costs.
http://www.nationalpriorities.org/costofwar_home
2.5 magnetic levitation /vacuum trains from London to New York. These puppies can get you from London to New York in 1 hour. They fly through tubes under the ocean that are almost at a total vacuum at 4000 mph on magnetic tracks. Much faster than flying.
http://www.klanrur.co.yu/forum/index.php?showtopic=45349
Pfff, in fact all of the US could be setup with coast to coast maglev links
http://en.wikipedia.org/wiki/Maglev_train#United_States
21 Manhattan projects
http://en.wikipedia.org/wiki/Manhattan_Project
1 600 $ tax rebate for every human alive in the US. That would stimulate the economy.
http://www.census.gov/main/www/popclock.html
35 Superconducting Super Colliders.. Physics would love you!
http://en.wikipedia.org/wiki/Superconducting_Super_Collider
34 ITER nuclear fusion reactors.. Wow.. that would be cool.
[This link is missing because X-Windows copy and paste is unreliable and I don't want to go find the stupid page again]
1 man on Mars. awww... looks like Bush wanted a war instead...
http://query.nytimes.com/gst/fullpage.html?res=950DE3D6163FF932A15752C1A96F948260
4 International Space Stations
http://en.wikipedia.org/wiki/International_Space_Station
340 Montreal Olympic Stadiums! (wow, that beast really was expensive)
http://en.wikipedia.org/wiki/Olympic_Stadium_(Montreal)
$3,749 per iraqi
http://zfacts.com/p/447.html
agh it goes on.. Carbon credits, electric car research, laptops for developing countries, UN back-dues...!
What's your favorite, expensive megaproject?
Tuesday, January 29, 2008
Sunday, January 13, 2008
beep
Hello, I can't come to the phone right now. If you'd leave me a message I'd get back to you as soon as possible.
Hi there. Umm.. It's Andrew. You know, I hate answering machines. They defeat the purpose of calling someone. I mean I might as well email or leave a message on any one of the billions of message-board style communication mediums. Frankly those are better because I'm not put in the unusual situation of having to come up with something without a backspace key.. Also, I've heard what I sound like on tape. I wouldn't wish that voice on anyone. This has been a long message. I'm surprised I haven't been cut off. Some of those cheap answering machines have so little space on them that you can barely get a message out. Have you noticed you always get cut off at a point that makes it sound like you're insane or insulting:
"Hi there, well, I've been thinking and I'm come to the conclusion that you're just as much an asshole as.." beep!
"Hi there, It's me again, I was about to say just as much an asshole as I've been so I really shouldn't be mad.. Ok, well if you.." beep!
agh!
Try calling back.. nope.. tape full. ha! You'll have to learn to talk in sound bites.
So, you known what. I'm not going to tell you why I've called. I'm going to leave you my number and get you on the phone so I can talk to you. I've got more to ask you from you than a question. I want more from you than a reply. So call me back. My number is
Hi there. Umm.. It's Andrew. You know, I hate answering machines. They defeat the purpose of calling someone. I mean I might as well email or leave a message on any one of the billions of message-board style communication mediums. Frankly those are better because I'm not put in the unusual situation of having to come up with something without a backspace key.. Also, I've heard what I sound like on tape. I wouldn't wish that voice on anyone. This has been a long message. I'm surprised I haven't been cut off. Some of those cheap answering machines have so little space on them that you can barely get a message out. Have you noticed you always get cut off at a point that makes it sound like you're insane or insulting:
"Hi there, well, I've been thinking and I'm come to the conclusion that you're just as much an asshole as.." beep!
"Hi there, It's me again, I was about to say just as much an asshole as I've been so I really shouldn't be mad.. Ok, well if you.." beep!
agh!
Try calling back.. nope.. tape full. ha! You'll have to learn to talk in sound bites.
So, you known what. I'm not going to tell you why I've called. I'm going to leave you my number and get you on the phone so I can talk to you. I've got more to ask you from you than a question. I want more from you than a reply. So call me back. My number is
Thursday, January 10, 2008
The fuzz point.
When trying to predict something, it is often the case that you need progressively more processing power as you increase the precision of your predictions. There's a point, however, at which increasing the amount of effort you put into creating the perfect prediction runs into the hard truth that either your model or your initial reading of the system's initial state limit your prediction's accuracy. Past this point, there's no reason to invest more effort because the amount of precision you'll have in your answer is more than the margin of error for that answer. This is the fuzz point. It is the point of diminishing returns.
It can show up in interesting places. My favorite place is the classic, intractable argument over aesthetics. If you just work at a little more it would look better. This isn't always the case. Consider your ability to predict what people find aesthetically pleasing. Consider any data you have on the topic and how much error there's likely to be. Consider the amount of time you've spent arguing about whether the arrow should be green or blue. You've past the fuzz point.
Aesthetics aren't unique. A special case of the fuzz point shows up when prioritizing. Bug fixes and feature in software.
How accurately can you predict how long something is going to take to fix?
How accurate can you be in predicting how important a feature is to implement?
How long are you going to argue about it?
The motto is, past the fuzz point, flipping a coin is actually cheaper in the long run.
The fuzz point is very small for small bug fixes. So small, in fact, that you get multiple different sorts of penalties.
In many shops all bug reports must be prioritized before it's decided whether or not they are worth doing. For bug fixes < 4 hours weird things start to happen.
The cost of figuring out if the bug is severe becomes more important.
The cost of tracking down the cause of the bug tends to be much more important.
The cost of the bureaucracy of fixing the problem becomes very important.
The cost of merely context switching away from to bug for enough time for it to be prioritizes becomes important.
The difficulty in measuring the relative importance of all these things increases.
Small bug fixing is fuzz point land. If a bug takes a short amount of time, there's no point in prioritizing it. The amount of time you've spent just trying to figure out the true severity and the cause dominate. If the fix is quick, don't prioritize, do it now, on the main branch and the deal with the risk portion of the bug fix separately. (Essentially review the severity and risk of each bug and fix and decide if they must be back ported to the old branch for a bug fix.. Also decide if it's worth running it by QA. The answer is almost certainly yes.).
If you do this, however, you will notice that you're development will stop. This isn't good. The way of getting around this is to allocate a fixed amount of resources to the task and prioritize bug fixing in its entirety with the adding of new features.
If you must prioritize fixes then poll the list of bugs looking for important ones. Don't force everything to be run through the bureaucracy before anyone can get a time budget for it.) .
If you implement this make sure you clearly say how long to spend in the various stages of bug tracking before giving up (how much time trying to ascertain the severity vs how much time investigating for each level of severity vs how much time trying to implement the fix). This is a heuristic but it works fairly well, because bug fixes show up in timesheets so you can see violations.
Must be going. I've been spending too long on this issue.
It can show up in interesting places. My favorite place is the classic, intractable argument over aesthetics. If you just work at a little more it would look better. This isn't always the case. Consider your ability to predict what people find aesthetically pleasing. Consider any data you have on the topic and how much error there's likely to be. Consider the amount of time you've spent arguing about whether the arrow should be green or blue. You've past the fuzz point.
Aesthetics aren't unique. A special case of the fuzz point shows up when prioritizing. Bug fixes and feature in software.
How accurately can you predict how long something is going to take to fix?
How accurate can you be in predicting how important a feature is to implement?
How long are you going to argue about it?
The motto is, past the fuzz point, flipping a coin is actually cheaper in the long run.
The fuzz point is very small for small bug fixes. So small, in fact, that you get multiple different sorts of penalties.
In many shops all bug reports must be prioritized before it's decided whether or not they are worth doing. For bug fixes < 4 hours weird things start to happen.
The cost of figuring out if the bug is severe becomes more important.
The cost of tracking down the cause of the bug tends to be much more important.
The cost of the bureaucracy of fixing the problem becomes very important.
The cost of merely context switching away from to bug for enough time for it to be prioritizes becomes important.
The difficulty in measuring the relative importance of all these things increases.
Small bug fixing is fuzz point land. If a bug takes a short amount of time, there's no point in prioritizing it. The amount of time you've spent just trying to figure out the true severity and the cause dominate. If the fix is quick, don't prioritize, do it now, on the main branch and the deal with the risk portion of the bug fix separately. (Essentially review the severity and risk of each bug and fix and decide if they must be back ported to the old branch for a bug fix.. Also decide if it's worth running it by QA. The answer is almost certainly yes.).
If you do this, however, you will notice that you're development will stop. This isn't good. The way of getting around this is to allocate a fixed amount of resources to the task and prioritize bug fixing in its entirety with the adding of new features.
If you must prioritize fixes then poll the list of bugs looking for important ones. Don't force everything to be run through the bureaucracy before anyone can get a time budget for it.) .
If you implement this make sure you clearly say how long to spend in the various stages of bug tracking before giving up (how much time trying to ascertain the severity vs how much time investigating for each level of severity vs how much time trying to implement the fix). This is a heuristic but it works fairly well, because bug fixes show up in timesheets so you can see violations.
Must be going. I've been spending too long on this issue.
Tuesday, January 1, 2008
HAPPY NEW YEAR!
I would like to wish all my friends a happy new year.. but I can't. I can't send them an email because that would be SPAM.. and I can't send them each an individual email because that would be an easily automated job and it's against computer programmer ethics to not be lazy in situations like this. I can't say HAPPY NEW YEAR! in my blog because only two people read it and I really want to tell everyone. I can't put "Andrew is wishing everyone a happy new!" in my facebook status because no one actually reads those things anyways. They exist only for self amusement and occasionally as an existential venting mechanism as in "Andrew is a spoon". Hummm.. I can't think of any way of doing it so I'll stick it in all these places and send personal notes to a few people arbitrarily. It's not perfect but it's the only way to avoid annoying myself.
Andrew is a fork.
Andrew is a fork.
Subscribe to:
Posts (Atom)
Posts
