We developed a rule of taking the engineers estimates and double them. Of course we're still running a little late;)
Of course you're running late.
Let me guess - you're a young pup. It's always been the same, since the dawn of history. Every generation laments that succceeding generation has to make the same mistakes, and learn the same lessons, over and over again.
IBM solved this estimation problem back when dinosaurs roamed the earth, virtually all computers were made by IBM, and they came with a "free" (as in beer) systems engineer.
IBM's solution was that every level of management that had to review an engieer's estimate would triple the estimate of the person who reported to (almost invariably) him. So, if the estimate required two levels of managerial approval, the quote to the client was 9 times what the engineers figured it should be. If three levels of approval were needed, the official estimate was 27 times what the engineers came up with. Now you know how IBM was able to afford that "free" systems engineer with every computer.
Actually, there are ways to drasticly increase the likelihood of success on "mission impossible" projects. I successfully led an EDI implementation project where there was no spec, no data, no customer, no access to the computers, the programming had to be done in an obscure language, and there was an arbitrarily set deadline of three weeks. Sometimes you take on such projects because you want to stretch yourself. But that's a story for another day.
You wrote: "In 1992, CEOs held 2 percent of the stock of US corporations, nowadays they own 12 percent. In less than 15 years, CEOs (not including other executives, just CEOs), have 'earned' themselves 10 whole percent of corporate America."
What is your source for this data? I'm not disagreeing. I've certainly seen a great increase in C level remuneration, but I've never seen it quantified this way before. Which CEOs? All corporations; Fortune 500; all publicly traded?
I'm putting together a multi-disciplinary project team to look into the homeostatic control processes (HCPs) in the human body in general and in the cardiovascular system in particular.
The objective is to learn how those HPCs work, how they fail and how they can be repaired or failure prevented.
The assumptions are:
The human body is, amongst other things, a very complex biochemical processing facility,
There are a vast number of homeostatic control processes in the human body,
Just as thousands of genes are coded for using only four DNA bases, the many different homeostatic control mechanisms are probably variations on a very
limited number of underlying control processes,
Combining insights from several different investigative and analytical disciplines is probably the best approach, and
Progress made in understanding any one HPC will likely help in understanding many others.
Who would you recommend for such a team?
Thanks in advance,
Morris Schneiderman
Morris at Projects Done Right dot com
Since most cells in the heart are "terminally differentiated" or incapable of generating new cells, where does cardiac scar tissue come from when some cardiac tissue dies?
Either some of those termianlly differentiated cells regress to an earlier state and then divide to create scar tissue, or scar tissue is the result of rapid division by cardiac stem cells, or there's something else happenning.
A lot of good stuff has been posted in this thread, but let me add a little more.
Success in a project such as this one requires an approach that pays attention to three factors. Ignoring even one of them will guarantee failure.
1. People: Can you use a design & development team of one person? If not, communication will be crucial. Get the best people you can who are willing to work together. Your people need experience working together.
2. Environment: Your team will need to be intimately familiar with both the development and live environments where this application will run. No one can be permitted to alter these environments once development starts. Don't even let them change the Uninteruptable Power Supply. I've seen a defective UPS introduce seemingly random errors into a rock solid production system! No other applications. No OS upgrades. Nothing!
3. Subject: You can neither design nor write good code if you don't fully understand the subject matter. What does the application do? Why is it important that this be done? Where does the input data come from? How and why is it generated? Who will use the outputs from your system? What will they do with those outputs? Why?
If your requirements are as stringent as you claim, select your team up front. Do not add anyone to the team (designers, coders, testers, documenters, project managers, etc. ) once you start the process outlined below. Everyone needs to be in it "for the duration".
Don't plan to do just one project. Plan for the team to do five projects using the environment. Plan for enough time to do it right. Plan for enough time for your people to get enough sleep. Plan for your team to not do any other applications until this one is finished. Do not reuse any code from project to project. The first four projects are learning projects.
Project 1: Team Building Project - Pick something relatively easy. The primary purpose of this project is for the team to become familiar with each other. The secondary purpose is for them to become familiar with the environments (OS, development tools, test tools, etc.) But this project (and all the others) must be taken seriously and produced to the same standard as your final product.
Project 2: Environment Test - Pick something that will push the environment to it's limits. Use every feature of the languages. Process numbers that are extremely small and extremely large. Process strings that are empty. Process strings that are huge and that contain all possible characters. Include all the "corner cases" you can imagine. Run it under high load, light load, no load and variable load. The purpose is not just to prove the environment, it's also for the team to gain an understanding of how the environment pushes back.
Project 3: Subject Matter Test - Pick something relatively simple to give your team experience with the subject matter and data that will be used in your ultimate project.
Project 4: Trial Run - Do a simplified version of your ultimate project. This is the place where your team gains experience with the core of the problem they will be addressing in the ultimate project.
Project 5: The Real Thing - This is where your team finally delivers what is wanted. Use a minimum of language features and system resources. Avoid doing anything "fancy". Keep it simple and organized. And remember, don't reuse any of the code from the earlier projects. Just use that you learned.
See, it's really easy. I've been producing high quality code for more than 35 years. And I learn something new on every project. This methodology won't guarantee success, but it sure will help you get there. Good luck.
If they want a sample of mantle rock, all they have to do is visit Newfoundland, Canada.
There's a valley in western Newfoundland where, on east side, the soil is derived from weathered crust material. On the west side, the 'soil' is mantle rock.
I've driven along a road in the bottom of the valley and the difference is striking! The east side is heavily overgrown. The west side has only a few blades of grass that seem to be growing in tiny pockets containing soil blown across the valley.
So, no drilling required. Just pick up a sample from the surface.
Starting as a geek with 25 years of software development and project management, I've spent the past year applying that project management experience to looking at the interaction between the heart and the arteries. And I can tell you that arteries are not simple.
First, artery walls are seven (7) layers thick. That's seven distinct types of cells and structures to print.
Second, the old theories viewed arteries merely as passive pipes connecting the heart to the capillaries. But as far back as 1733, Hales understood that the arteries are pumps. He saw them as passive pumps, expanding when blood was pumped into them, and then contracting due to their elastic membranes after each heartbeat. Observations made 50 years ago by McDonald and now being reinterpreted in light of additional data strongly suggests that the arteries are active pumps. (I'll spare you the details, but it adds at least an order of magnitude to the complexity of the 'image'.)
Third, there are at least two sets of nerves that run through the outer wall of the arteries, the sympathetic and parasympathetic. These nerves seem to exert control over the contraction and relaxation of the smooth muscle in the artery wall. We don't yet understand the intricacies of the processes that control the phasing of those contractions and relaxations, but degredation in those control processes seems to be the mechanism behind the development of heart failure. While these nerves will have to be 'printed' and 'wired up' (no USB connections), it's not clear that their connections to the brain are the only contol paths. There may well be other, currently unknown, 'jumpers' that are needed. Closed source software isn't the only thing with undocumented APIs.
So, there are reasons why teflon tubing is not being used as a replacement for arteries. And those reasons will make it hard (but not necessarily impossible) to print arteries. I wish them well. But don't hold your breath. Do take care of your body - it's the only one you have and will continue to be so for quite a while yet.
I've lived long enough and travelled widely enough to know, from personal observation, that global warming is happening.
But it's not as simple as that.
First, I am aware of a large exception - an area of regional cooling caused by human activity. The coastal area of Labrador in Canada is cooling dramatically. This is caused by the huge Churchill Falls hydro-electric power development that's been sending energy to the US north-east.
Second, our current global warming is not the world's first. If you travel in the upper reaches of many of the world's mountain ranges you will see lateral moraines left over from previous periods of glacial advance.
But, to what extent is all this the result of human activity and to what extent is it the result of fluctuations in the sun's energy output? That I don't know.
Exactly so. I've accomplished similar things the same way in very large corporations. Except, I limit my direct effort to 8am to 6pm, five days a week and let my subconscious work on the other shifts.
"it took NASA only 7 years" because they hired many of the engineers and middle managers that had been fired by Avrow in Toronto when the new Canadian government cancelled production of the Avrow Arrow jet fighter.
Those guys had considerable experience pushing aerospace technology. In 1949 (yes, you read that correctly) they completed construction and successfully flew a 40 passenger jet airplane with a range of 1400 miles and an air speed of 427 mph.
The Avro Arrow jet fighter first flew in July, 1952 (yes, you read that right, too). It was a fully armoured, mach 2.0 fighter jet.
Other projects COMPLETED by their engineering department included:
1955 Small subsonic jet transport (business jet)
1955 VTOL fighter project
1956 Long range jet transport
1957 P-13 anti-missile missile
1958 Monorail
1958 Supersonic cheap interceptor missile
1958 Ballistic drag re-entry vehicle
1958 Space threshold vehicle
1959 Supersonic trans-atlantic transport studies
Now you know why "it took NASA only 7 years" - and why they could not do it again today.
Five Reasons Why Projects Fail ... and how to keep yours from doing so.
Most people are familiar with the 34% success rate of projects, as reported in the Standish Group 2003 Chaos Report. Whether the success of your project depends upon juggling hundreds of details, or hundreds of thousands of details, there are two basic ways that projects fail. They either fail completely - delivering nothing of value, or they fail to deliver a significant portion of the benefit that they could have yielded.
Under-Deliver
There are two basic reasons why projects under-deliver:
Limited Objective: "We anticipate growing at 10% per year if you can eliminate the paperwork bottlenecks that are choking our business."
Predetermined Solution: "We want you to develop a computerized dispatching system for us."
Fail Completely
There are three basic reasons why projects fail completely:
Lack of Vision: "But we've always done it this way, and so has everyone else."
Lack of Commitment: "We're just too busy to get this done."
Lack of Resources: "I know you want to win a $30 million contract for the company, but we're too busy to help."
Download your own pdf copy of this Special Report: Why Projects Fail.
What Unix needs is a compiler (pick your favorite language) that generates code which prevents buffer overflows. Checking for buffer overflows should be a system function with application level override.
I downloaded Antiviron onto an old, 300MHz laptop running W98SE, installed it non-resident, and ran it. It took close to an hour to scan 40,000+ files and reported no problems.
However, after that, it would take 'forever' (over a minute) to open a file by double-clicking on it. (Previously took several seconds.)
So I tried to use the Uninstaller included with AntiVir. Tried it twice. Both times it hung the system.
Please, someone, ask Sid Meiers (of Civilization) to help. He knew more about effective User Interfaces 15 years ago than anyone else seems to know today.
Even back in the days of Railroad Tycoon, he was able to present understandable and usable information at the single pixle level.
User Interface does not, and should not, mean "looks like MS Windows".
If Sid Meiers isn't willing to help (lead) the effort, then study his best work before starting.
"As AI research progresses, we will be able to build robots capable of doing service jobs. The health care crisis will be 'solved' during the second half of the 21st century. Robots will replace, not only orderlies and nurses, but physicians and surgeons, too. The cost of producing these robots will be minimal. The valuable commodity will be the knowledge of how to program them to do what you want them to do.
By the end of the 21st century, creativity -- the creation of intellectual property -- will be the only currently known role that will still be the domain of us humans. And the control of that creativity is what is being fought for now.
That's the power struggle going on now. It's just started. One more thing. By the end of the 21st century, molecular genetics will have progressed to the point where most people will be able to live almost forever. Imagine living forever in a world where production and services basically cost nothing. The only thing of value will be control of the intellectual property behind it all.
Imagine a world where material items sell for a dollar each and services are provided for ten cents an hour. It could be paradise if you have the money to pay for what you want. But if you don't, how do you compete against such prices?
The challenge as we approach the 22nd century will be to rethink the issues of access. How will we reward innovation while making it possible for most people to survive and live reasonably good lives? Because, if most people cannot pay for those goods and services, there will be a revolution. If that revolution succeeds, those who were on top will be gone. If the revolution fails, the whole economic system will collapse from lack of customers.
Hang onto your hat. It's going to be a wild ride."
Until 100 years ago, almost everyone on earth lived with shortages. While a few were rich, most people seldom even had enough to eat.
The 20th century was incredible. We acquired the ability to produce food and goods to satisfy the needs of everyone on earth, though we did not make them available to everyone.
We have had two major power struggles during the 20th century. At the beginning, production was 'difficult', so those who could produce were able to 'call the shots'. WW II was a war of production and it was wonn by the side that was able to produce the most bombs and bullets.
Since then, productivity has continued to improve. Production is no longer the 'hard part'. The challenge during the past few decades has been to convince people to buy. Hence marketing has become king. Between 3rd world labor and automation, production costs have fallen dramatically. For most products, the major costs are Marketing & Distribution and R&D.
But the smart folks have recognized that the 21st century will be even more unsettling than the 20th century. Computer controlled extraction of natural resources and production (including nanotechnology) can drive manufacturing costs to almost zero. (Go read 'A for Anything' , by Damon Knight) With the Internet, we will be able to distribute the knowledge of how to produce. This will eliminate most of the challenges associated with distribution (since it will be possible to do most production locally, so there will be little money to be made there either, unless artificial controls and impediments are implemented.
This is why there's such a fight for intellectual property rights. Only by controlling the knowledge of how and what to produce can power be maintained by those who value it. By the middle of the 21st century, the major cost of any material item will be the 'intellectual property' charge.
With production automated, almost everyone who is employed will be working in service jobs by 2050. And then it gets more interesting.
As AI research progresses, we will be able to build robots capable of doing service jobs. The health care crisis will be 'solved' during the second half of the 21st century. Robots will replace, not only orderlies and nurses, but physicians and surgeons, too. The cost of producing these robots will be minimal. The valuable commodity will be the knowledge of how to program them to do what you want them to do.
By the end of the 21st century, creativity -- the creation of intellectual property -- will be the only currently known role that will still be the domain of us humans. And the control of that creativity is what is being fought for now.
That's the power struggle going on now. It's just started.
One more thing. By the end of the 21st century, molecular genetics will have progressed to the point where most people will be able to live almost forever. Imagine living forever in a world where production and services basically cost nothing. The only thing of value will be control of the intellectual property behind it all. Imagine a world where material items sell for a dollar each and services are provided for ten cents an hour. It could be paradise if you have the money to pay for what you want. But if you don't, how do you compete against such prices?
The challenge as we approach the 22nd century will be to rethink the issues of access. How will we reward innovation while making it possible for most people to survive and live reasonably good lives?
Because, if most people cannot pay for those goods and services, there will be a revolution. If that revolution succeeds, those who were on top will be gone. If the revolution fails, the whole economic system will collapse from lack of customers.
The ONLY practical way to eliminate buffer overflow exploits is to develop and use a compiler that does not permit buffer overflows. This means proper compiler design (optimized for functionality, not speed), thorough audits of the compiler code and a robust test program for the compiler.
Even with this approach, it will be years before all the 'bad' code out there is replaced by new code that cannot cause buffer overflows. But I see no other way to put an end to this 'madness'.
Almost 20 years ago I went to NASA for an 'electrical safety review' for a small payload we were developing. The review was conducted by an 'electrical safety expert' consultant.
The payload was quite simple, but it required astronauts to occasionally toggle switches from one position to another. (You don't want to vent the payload until after the shuttle bay doors are open, or during an EVA, etc.)
We had determined the sequence of events and their approximate timing, but their precise timing would have to be integrated into mission operations.
The 'electical safety expert' reviewed the design and approved it. He also expressed amazement. We used relays to prepare each circuit. If you inadvertantly threw a switch out of sequence, nothing would happen, because the circuit would not be complete. We could not prevent an Astronaut from accidentally toggling the wrong switch, but we could (and did) prevent such action from being detrimental. We also made it possible to correct the mistake without consequence. The 'electrical safety expert' had "never seen such a thing".
The bit about encouraging each person on the team to find something in the project that really motivates him or her, really makes sense.
But other than that, the concept of a bunch of people trying to 'reveal the elephant' through individual efforts is probably why so many projects fail or produce sub-optimal results.
Projects vary in many ways. The most significant is often Uncertainty. Towards one end of the continuum we have the Recipe Book project:- "We've done something very similar before - we have the recipe and we know how to follow it". Towards the other end, we have the Wilderness Exploration project:- "We have an idea of where we want to end up, but we really don't know how we will get there, how long the journey will take, nor what adventures may arise on the way."
There are a host of skills and techniques that can help in such situations. One of the most applicable general methodologies that I've learned is the Canadain Method. It was first introduced (so far as I know) to capture Vimy Ridge in World War One. The capture took one day and cost the Canadians 3,500 fatalities and 7,000 wounded. British and French efforts had previously cost over 200,000 lives and produced no significant results during two years.
Twenty plus years of leading projects has given me considerable insight into "The Art and Science of Making the Future Happen."
1. I have not read Dr. Partridge's research, so we may be taking things out of context, but if "The system has no memory" then when and why would anyone die, except from trauma?
2. Perhaps, 48 hours after going to low caloric intake, the cells slow down their metabolic rate. In that case, the 'life extension' value would seem to be some percent of your 'remaining life' at normal caloric input.
I published some of the initial, theoretical work behind this, in 1981 in a journal called Speculations in Science and Technology, vol. 4 no. 3. page 335.
It used to be 'common knowledge' that fully differentiated cells of a given tissue type would each live for a specific length of time and then die.
I argued that this was not so. I suggested that fully differentiated cells of a given tissue type would divide a specific number of times and then stop dividing (Hayflick Limit). I hypothesized the existence of a counter in each cell that kept track of how many more times that cell could divide. Today, those counters are called Tellomeres.
The reason you live longer on a low calorie diet is because your individual cells don't have the fuel to go through their life cycles as quickly. Give them the fuel and they speed up again.
So the idea of waiting until 48 hours before your natural dead would not extend your life by much at all. Sorry.
Tellomeres are like a chain of knots at one end of the DNA. Each time the DNA divides, there's one less knot on the chain. If the cell does not become cancerous, when there are no more knots, the cell ceases to divide. The real answer to life extension will be when we learn how to add knots back onto the Tellomeres.
I expect this problem to be solved within the next 15 years. At that point, it will become possible to slowly roll back the age of the body as, for example, 46th generation smooth muscle cells divide and become 17th generation smooth muscle cells. Over a period of several years your body would effectively become younger.
Slashdot Mirror
Of course you're running late.
Let me guess - you're a young pup. It's always been the same, since the dawn of history. Every generation laments that succceeding generation has to make the same mistakes, and learn the same lessons, over and over again.
IBM solved this estimation problem back when dinosaurs roamed the earth, virtually all computers were made by IBM, and they came with a "free" (as in beer) systems engineer.
IBM's solution was that every level of management that had to review an engieer's estimate would triple the estimate of the person who reported to (almost invariably) him. So, if the estimate required two levels of managerial approval, the quote to the client was 9 times what the engineers figured it should be. If three levels of approval were needed, the official estimate was 27 times what the engineers came up with. Now you know how IBM was able to afford that "free" systems engineer with every computer.
Actually, there are ways to drasticly increase the likelihood of success on "mission impossible" projects. I successfully led an EDI implementation project where there was no spec, no data, no customer, no access to the computers, the programming had to be done in an obscure language, and there was an arbitrarily set deadline of three weeks. Sometimes you take on such projects because you want to stretch yourself. But that's a story for another day.
You wrote: "In 1992, CEOs held 2 percent of the stock of US corporations, nowadays they own 12 percent. In less than 15 years, CEOs (not including other executives, just CEOs), have 'earned' themselves 10 whole percent of corporate America."
What is your source for this data? I'm not disagreeing. I've certainly seen a great increase in C level remuneration, but I've never seen it quantified this way before. Which CEOs? All corporations; Fortune 500; all publicly traded?
The objective is to learn how those HPCs work, how they fail and how they can be repaired or failure prevented.
The assumptions are:
- The human body is, amongst other things, a very complex biochemical processing facility,
- There are a vast number of homeostatic control processes in the human body,
- Just as thousands of genes are coded for using only four DNA bases, the many different homeostatic control mechanisms are probably variations on a very
limited number of underlying control processes,
- Combining insights from several different investigative and analytical disciplines is probably the best approach, and
- Progress made in understanding any one HPC will likely help in understanding many others.
Who would you recommend for such a team?Thanks in advance,
Morris Schneiderman
Morris at Projects Done Right dot com
Since most cells in the heart are "terminally differentiated" or incapable of generating new cells, where does cardiac scar tissue come from when some cardiac tissue dies?
Either some of those termianlly differentiated cells regress to an earlier state and then divide to create scar tissue, or scar tissue is the result of rapid division by cardiac stem cells, or there's something else happenning.
Does anyone have any data on this?
Purple grape juice reportedly has the same beneficial effects.
A lot of good stuff has been posted in this thread, but let me add a little more.
Success in a project such as this one requires an approach that pays attention to three factors. Ignoring even one of them will guarantee failure.
1. People: Can you use a design & development team of one person? If not, communication will be crucial. Get the best people you can who are willing to work together. Your people need experience working together.
2. Environment: Your team will need to be intimately familiar with both the development and live environments where this application will run. No one can be permitted to alter these environments once development starts. Don't even let them change the Uninteruptable Power Supply. I've seen a defective UPS introduce seemingly random errors into a rock solid production system! No other applications. No OS upgrades. Nothing!
3. Subject: You can neither design nor write good code if you don't fully understand the subject matter. What does the application do? Why is it important that this be done? Where does the input data come from? How and why is it generated? Who will use the outputs from your system? What will they do with those outputs? Why?
If your requirements are as stringent as you claim, select your team up front. Do not add anyone to the team (designers, coders, testers, documenters, project managers, etc. ) once you start the process outlined below. Everyone needs to be in it "for the duration".
Don't plan to do just one project. Plan for the team to do five projects using the environment. Plan for enough time to do it right. Plan for enough time for your people to get enough sleep. Plan for your team to not do any other applications until this one is finished. Do not reuse any code from project to project. The first four projects are learning projects.
Project 1: Team Building Project - Pick something relatively easy. The primary purpose of this project is for the team to become familiar with each other. The secondary purpose is for them to become familiar with the environments (OS, development tools, test tools, etc.) But this project (and all the others) must be taken seriously and produced to the same standard as your final product.
Project 2: Environment Test - Pick something that will push the environment to it's limits. Use every feature of the languages. Process numbers that are extremely small and extremely large. Process strings that are empty. Process strings that are huge and that contain all possible characters. Include all the "corner cases" you can imagine. Run it under high load, light load, no load and variable load. The purpose is not just to prove the environment, it's also for the team to gain an understanding of how the environment pushes back.
Project 3: Subject Matter Test - Pick something relatively simple to give your team experience with the subject matter and data that will be used in your ultimate project.
Project 4: Trial Run - Do a simplified version of your ultimate project. This is the place where your team gains experience with the core of the problem they will be addressing in the ultimate project.
Project 5: The Real Thing - This is where your team finally delivers what is wanted. Use a minimum of language features and system resources. Avoid doing anything "fancy". Keep it simple and organized. And remember, don't reuse any of the code from the earlier projects. Just use that you learned.
See, it's really easy. I've been producing high quality code for more than 35 years. And I learn something new on every project. This methodology won't guarantee success, but it sure will help you get there. Good luck.
Morris
If they want a sample of mantle rock, all they have to do is visit Newfoundland, Canada.
There's a valley in western Newfoundland where, on east side, the soil is derived from weathered crust material. On the west side, the 'soil' is mantle rock.
I've driven along a road in the bottom of the valley and the difference is striking! The east side is heavily overgrown. The west side has only a few blades of grass that seem to be growing in tiny pockets containing soil blown across the valley.
So, no drilling required. Just pick up a sample from the surface.
Could you provide a link to Greg Cochran's paper? I'm starting to suspect an infectious role in triggering several chronic conditions.
Starting as a geek with 25 years of software development and project management, I've spent the past year applying that project management experience to looking at the interaction between the heart and the arteries. And I can tell you that arteries are not simple.
First, artery walls are seven (7) layers thick. That's seven distinct types of cells and structures to print.
Second, the old theories viewed arteries merely as passive pipes connecting the heart to the capillaries. But as far back as 1733, Hales understood that the arteries are pumps. He saw them as passive pumps, expanding when blood was pumped into them, and then contracting due to their elastic membranes after each heartbeat. Observations made 50 years ago by McDonald and now being reinterpreted in light of additional data strongly suggests that the arteries are active pumps. (I'll spare you the details, but it adds at least an order of magnitude to the complexity of the 'image'.)
Third, there are at least two sets of nerves that run through the outer wall of the arteries, the sympathetic and parasympathetic. These nerves seem to exert control over the contraction and relaxation of the smooth muscle in the artery wall. We don't yet understand the intricacies of the processes that control the phasing of those contractions and relaxations, but degredation in those control processes seems to be the mechanism behind the development of heart failure. While these nerves will have to be 'printed' and 'wired up' (no USB connections), it's not clear that their connections to the brain are the only contol paths. There may well be other, currently unknown, 'jumpers' that are needed. Closed source software isn't the only thing with undocumented APIs.
So, there are reasons why teflon tubing is not being used as a replacement for arteries. And those reasons will make it hard (but not necessarily impossible) to print arteries. I wish them well. But don't hold your breath. Do take care of your body - it's the only one you have and will continue to be so for quite a while yet.
Morris
As I recall, the first few orbiter flights used cork, painted white, to insulate the external fuel tank. I don't know why they changed to foam.
I've lived long enough and travelled widely enough to know, from personal observation, that global warming is happening.
But it's not as simple as that.
First, I am aware of a large exception - an area of regional cooling caused by human activity. The coastal area of Labrador in Canada is cooling dramatically. This is caused by the huge Churchill Falls hydro-electric power development that's been sending energy to the US north-east.
Second, our current global warming is not the world's first. If you travel in the upper reaches of many of the world's mountain ranges you will see lateral moraines left over from previous periods of glacial advance.
But, to what extent is all this the result of human activity and to what extent is it the result of fluctuations in the sun's energy output? That I don't know.
Exactly so. I've accomplished similar things the same way in very large corporations. Except, I limit my direct effort to 8am to 6pm, five days a week and let my subconscious work on the other shifts.
Morris
A good story-teller never lets the true get in the way of a good story.
Those guys had considerable experience pushing aerospace technology. In 1949 (yes, you read that correctly) they completed construction and successfully flew a 40 passenger jet airplane with a range of 1400 miles and an air speed of 427 mph.
The Avro Arrow jet fighter first flew in July, 1952 (yes, you read that right, too). It was a fully armoured, mach 2.0 fighter jet.
Other projects COMPLETED by their engineering department included:
1955 Small subsonic jet transport (business jet) 1955 VTOL fighter project 1956 Long range jet transport 1957 P-13 anti-missile missile 1958 Monorail 1958 Supersonic cheap interceptor missile 1958 Ballistic drag re-entry vehicle 1958 Space threshold vehicle 1959 Supersonic trans-atlantic transport studies
Now you know why "it took NASA only 7 years" - and why they could not do it again today.
Most people are familiar with the 34% success rate of projects, as reported in the Standish Group 2003 Chaos Report. Whether the success of your project depends upon juggling hundreds of details, or hundreds of thousands of details, there are two basic ways that projects fail. They either fail completely - delivering nothing of value, or they fail to deliver a significant portion of the benefit that they could have yielded.
Download your own pdf copy of this Special Report:
Why Projects Fail.
From: http://www.projectsdoneright.com/pdr/pdrPapersWhy
What Unix needs is a compiler (pick your favorite language) that generates code which prevents buffer overflows. Checking for buffer overflows should be a system function with application level override.
I downloaded Antiviron onto an old, 300MHz laptop running W98SE, installed it non-resident, and ran it. It took close to an hour to scan 40,000+ files and reported no problems.
However, after that, it would take 'forever' (over a minute) to open a file by double-clicking on it. (Previously took several seconds.)
So I tried to use the Uninstaller included with AntiVir. Tried it twice. Both times it hung the system.
How can I get rid of AntiVir?
Thanks in advance,
Morris
Please, someone, ask Sid Meiers (of Civilization) to help. He knew more about effective User Interfaces 15 years ago than anyone else seems to know today.
Even back in the days of Railroad Tycoon, he was able to present understandable and usable information at the single pixle level.
User Interface does not, and should not, mean "looks like MS Windows".
If Sid Meiers isn't willing to help (lead) the effort, then study his best work before starting.
By the end of the 21st century, creativity -- the creation of intellectual property -- will be the only currently known role that will still be the domain of us humans. And the control of that creativity is what is being fought for now.
That's the power struggle going on now. It's just started. One more thing. By the end of the 21st century, molecular genetics will have progressed to the point where most people will be able to live almost forever. Imagine living forever in a world where production and services basically cost nothing. The only thing of value will be control of the intellectual property behind it all.
Imagine a world where material items sell for a dollar each and services are provided for ten cents an hour. It could be paradise if you have the money to pay for what you want. But if you don't, how do you compete against such prices?
The challenge as we approach the 22nd century will be to rethink the issues of access. How will we reward innovation while making it possible for most people to survive and live reasonably good lives? Because, if most people cannot pay for those goods and services, there will be a revolution. If that revolution succeeds, those who were on top will be gone. If the revolution fails, the whole economic system will collapse from lack of customers.
Hang onto your hat. It's going to be a wild ride."
From: www.ProjectsDoneRight.com/pdr/pdrPapersIP.asp
The 20th century was incredible. We acquired the ability to produce food and goods to satisfy the needs of everyone on earth, though we did not make them available to everyone.
We have had two major power struggles during the 20th century. At the beginning, production was 'difficult', so those who could produce were able to 'call the shots'. WW II was a war of production and it was wonn by the side that was able to produce the most bombs and bullets.
Since then, productivity has continued to improve. Production is no longer the 'hard part'. The challenge during the past few decades has been to convince people to buy. Hence marketing has become king. Between 3rd world labor and automation, production costs have fallen dramatically. For most products, the major costs are Marketing & Distribution and R&D.
But the smart folks have recognized that the 21st century will be even more unsettling than the 20th century. Computer controlled extraction of natural resources and production (including nanotechnology) can drive manufacturing costs to almost zero. (Go read 'A for Anything' , by Damon Knight) With the Internet, we will be able to distribute the knowledge of how to produce. This will eliminate most of the challenges associated with distribution (since it will be possible to do most production locally, so there will be little money to be made there either, unless artificial controls and impediments are implemented.
This is why there's such a fight for intellectual property rights. Only by controlling the knowledge of how and what to produce can power be maintained by those who value it. By the middle of the 21st century, the major cost of any material item will be the 'intellectual property' charge.
With production automated, almost everyone who is employed will be working in service jobs by 2050. And then it gets more interesting.
As AI research progresses, we will be able to build robots capable of doing service jobs. The health care crisis will be 'solved' during the second half of the 21st century. Robots will replace, not only orderlies and nurses, but physicians and surgeons, too. The cost of producing these robots will be minimal. The valuable commodity will be the knowledge of how to program them to do what you want them to do.
By the end of the 21st century, creativity -- the creation of intellectual property -- will be the only currently known role that will still be the domain of us humans. And the control of that creativity is what is being fought for now.
That's the power struggle going on now. It's just started.
One more thing. By the end of the 21st century, molecular genetics will have progressed to the point where most people will be able to live almost forever. Imagine living forever in a world where production and services basically cost nothing. The only thing of value will be control of the intellectual property behind it all. Imagine a world where material items sell for a dollar each and services are provided for ten cents an hour. It could be paradise if you have the money to pay for what you want. But if you don't, how do you compete against such prices?
The challenge as we approach the 22nd century will be to rethink the issues of access. How will we reward innovation while making it possible for most people to survive and live reasonably good lives?
Because, if most people cannot pay for those goods and services, there will be a revolution. If that revolution succeeds, those who were on top will be gone. If the revolution fails, the whole economic system will collapse from lack of customers.
Hang onto your hat. It's going to be a wild ride.
From: http://www.ProjectsDoneRight.com/pdr/pdrPapersIP.a sp
The ONLY practical way to eliminate buffer overflow exploits is to develop and use a compiler that does not permit buffer overflows. This means proper compiler design (optimized for functionality, not speed), thorough audits of the compiler code and a robust test program for the compiler.
Even with this approach, it will be years before all the 'bad' code out there is replaced by new code that cannot cause buffer overflows. But I see no other way to put an end to this 'madness'.
Almost 20 years ago I went to NASA for an 'electrical safety review' for a small payload we were developing. The review was conducted by an 'electrical safety expert' consultant.
The payload was quite simple, but it required astronauts to occasionally toggle switches from one position to another. (You don't want to vent the payload until after the shuttle bay doors are open, or during an EVA, etc.)
We had determined the sequence of events and their approximate timing, but their precise timing would have to be integrated into mission operations.
The 'electical safety expert' reviewed the design and approved it. He also expressed amazement. We used relays to prepare each circuit. If you inadvertantly threw a switch out of sequence, nothing would happen, because the circuit would not be complete. We could not prevent an Astronaut from accidentally toggling the wrong switch, but we could (and did) prevent such action from being detrimental. We also made it possible to correct the mistake without consequence. The 'electrical safety expert' had "never seen such a thing".
But other than that, the concept of a bunch of people trying to 'reveal the elephant' through individual efforts is probably why so many projects fail or produce sub-optimal results.
Projects vary in many ways. The most significant is often Uncertainty. Towards one end of the continuum we have the Recipe Book project:- "We've done something very similar before - we have the recipe and we know how to follow it". Towards the other end, we have the Wilderness Exploration project:- "We have an idea of where we want to end up, but we really don't know how we will get there, how long the journey will take, nor what adventures may arise on the way."
There are a host of skills and techniques that can help in such situations. One of the most applicable general methodologies that I've learned is the Canadain Method. It was first introduced (so far as I know) to capture Vimy Ridge in World War One. The capture took one day and cost the Canadians 3,500 fatalities and 7,000 wounded. British and French efforts had previously cost over 200,000 lives and produced no significant results during two years.
Twenty plus years of leading projects has given me considerable insight into "The Art and Science of Making the Future Happen."
If you want to read the first chapter of the distillation of this experience, you can find it at: http://www.ProjectsDoneRight.com/pdr/pdrBook.asp
2. Perhaps, 48 hours after going to low caloric intake, the cells slow down their metabolic rate. In that case, the 'life extension' value would seem to be some percent of your 'remaining life' at normal caloric input.
It used to be 'common knowledge' that fully differentiated cells of a given tissue type would each live for a specific length of time and then die.
I argued that this was not so. I suggested that fully differentiated cells of a given tissue type would divide a specific number of times and then stop dividing (Hayflick Limit). I hypothesized the existence of a counter in each cell that kept track of how many more times that cell could divide. Today, those counters are called Tellomeres.
The reason you live longer on a low calorie diet is because your individual cells don't have the fuel to go through their life cycles as quickly. Give them the fuel and they speed up again.
So the idea of waiting until 48 hours before your natural dead would not extend your life by much at all. Sorry.
Tellomeres are like a chain of knots at one end of the DNA. Each time the DNA divides, there's one less knot on the chain. If the cell does not become cancerous, when there are no more knots, the cell ceases to divide. The real answer to life extension will be when we learn how to add knots back onto the Tellomeres.
I expect this problem to be solved within the next 15 years. At that point, it will become possible to slowly roll back the age of the body as, for example, 46th generation smooth muscle cells divide and become 17th generation smooth muscle cells. Over a period of several years your body would effectively become younger.