Back in the 70's and 80's Senator William Proxmire (D - Wisconsin) handed out 'Golden Fleece' awards to groups that were doing things that he considered to be a waste of tax payers money.
I believe that one of the awards went to a group that was trying to reduce flatulence in cows.
It is interesting how said research has relevance today.
It is even more interesting that Proxmire represented a state that got a lot of price supports for the dairy industry.
Not all ag land is suitable for growing crops that are human consumable. That is one of the problems with the 'soy' argument.
Properly handled, a lot of this marginal ag land works well for grazing. Unfortunately, there are a lot of greedy types that overgraze the land and cause problems.
At the same time, there are a lot of crop growing types that abuse the land and cause problems too.
Woot first point for the day. As usual idealists live in a 1 dimensional universe where they again fail to see the whole cost beyound the end of their nose.
He isn't on to something, and anyone that thinks this is a great idea is a stark raving idiot.
A: Treadmills don't far well outside. More roofed covered space. Nor to treadmills grow on trees.
B: Carbon footprint for the manfacturing of said treadmills
C: Additional feed for active cows now burning more calories. More waste from more feed too
D: Energy loss in conversion to heat from friction from transmission points
E: More wiring and cabling sucking down more copper from an already stressed raw material market. Ohms.....Ohms.....
F: Who in their right mind thinks: taking solar energy and water and converting it into biomass
Then using millions of tons of fossil fuels to build machinery to develop and harvest biomass.
Feed said biomass to another animal
To use millions of tons of fossil fuels in manufacturing a kinetic engery transfomation device (treadmill)
To then power a machine to generate a fraction of the energy "THE SUN PUT OUT IN THE FIRST PLACE!?
Jebus Rice we are getting shit-eating stupid pretty damn fast when people think "Hey they're on to something..."
Narrow minded morons never looking past their own nose on what real costs are.
A. We're talking about ag quality treadmills, not human quality. Ag equipment tends to be designed to handle weather, dirt and manure while lasting a lot longer than treadmills meant for humans.
B. While manufacturing/maintaining the treadmills has a carbon footprint, so does getting power from non-treadmill generators to the milking machines.
C. Is that much additional feed needed? Farmers do have to consider feed costs in all the things they do. If they are lucky, they have their own feed sources or feed sources that are close by. I do recall one version of the article claiming that the cows wouldn't be any more active on the treadmill than they would be in the field.
D. All conversion systems have energy losses. To minimize these losses you need to get the generator as close to the end user as possible. In this case, the cow powered treadmill could be used to power the equipment used to milk the cow powering the treadmill, with an offset due to timing. (Batteries would likely be needed, or some sort of schedule that has X cows on the treadmills while Y cows are being milked.)
E. When considering the cost of copper, you also need to consider the demands that the solar industry and the wind power industry are putting on the market. Is the amount of material required for treadmills, with their reduced point to point losses, less than the amount of material needed to move power from solar and wind farms?
F. You might consider the treadmill idea to be more a case of trying to use an unused resource as opposed to creating a new power system. If the total value, financial and environmental, of the power generated exceeds the total cost, financial and environmental, of the equipment and other resources needed to generate that power, then it is a good idea. Note that these factors WILL vary location. Also note that the person promoting the idea wanted to reduce his dependency on fossil fuels. (In an area with lots of water and a good climate for growing hay, this could be done by using horses as opposed to tractors.)
General Comment: To be completely fair to all points of view, the cost/benefit analysis needs to consider all of the above and more before accepting or rejecting the idea.
You might want to differentiate between beef and dairy cows. A lot of grain is used to fatten up beef cattle for the market, after the cattle are fed on the range. This 'finishing' process is one of the reasons why there are stock yards.
Still, because producing milk takes a lot of protein, corn or other high protein substances are needed to supplement forage that comes in the form of hay or even grass if you are lucky enough to have a source of water. Grass or hay doesn't quite hack it.
Do note that using corn for ethanol is fairly wasteful and is one of the reasons that food prices have gone up. It is much better to use non-food vegetation for ethanol production.
Balancing all the inputs and outputs can get pretty complex, which is why ag majors were learning how to use linear programming based programs over three decades ago. Said programs allowed them to come up with cost effective grain-forage-supplement mixes for feeding beef and dairy cattle.
According to the source article I read, the treadmill seems to help cows reduce methane production. The idea is that cows that don't move around are more gassy than cows that move around.
I once worked for a software company where the owner said that programmers should not work more than forty hours a week, except in VERY rare emergencies. He based that on the observation that the programming done after the eight hour a day limit often required reworking, thus negating the gains achieved by overtime.
As far as my maximum effectiveness level, I could usually do about twenty hours hours of programming a week, including doing pseudo-code for some of the more complex bits of code. The rest of the time was spent in testing, tweaking and making sure that the new code works as desired, plus the standard overhead of keeping up the skill sets.
I consider the process of programming to be a job that requires a lot of brain sweat if you are trying for something that works and works well. After you reach a limit your mind needs a break, otherwise you end up with headaches or other stress related problems.
The roads like this are often called freeways or highways, and involve separating various types of traffic. Sometimes they are even special arterials with extra wide landscape areas surrounding them.
Unfortunately, traffic from these forms of road eventually mixes with residential, commercial and other land uses that involve people not in vehicles, which is where you need to slow things down. While you could continue separating vehicle traffic from other forms of traffic, it becomes extremely expensive. (Imagine having vehicle only tunnels to every home, business or other location. Or imagine prohibiting people from using roads unless they are in an approved vehicle.)
Fast isn't safe when vehicles and pedestrians interact.
Unless I'm making a long, cross country trip, the amount I pay in taxes for transportation bond issues is greater than the amount I pay in gas taxes on a yearly basis. And this is in a state with fairly high gas taxes.
That ignores the money that comes from the general fund and other sources like license fees. It also ignores the 'hidden' taxes for the transportation oriented services provided by the fire department, the police department and other services.
As more roundabouts are installed, more people will get used to them. I suspect that the traffic engineers anticipated the problem and figured that it would go away in time. The fact that there is confusion gets people to slow down, which shows that they do work, even when people aren't used to them.
While the roundabouts may or may not reduce the total number of accidents, I wouldn't be surprised if they reduced the severity of the accidents. Their geometry forces people to slow down so that it becomes a lot more difficult to have high speed t-bone accidents.
I get the feeling that a lot of people object to the idea of slowing down traffic in urban areas. After all, it keeps them from getting to their destination as fast as possible.
At the same time, these same people would probably welcome slower traffic IF they lived in and around these areas and were threatened by faster traffic. People are odd that way.
It reminds me of a situation where a city council had two major groups: developers and environmentalists. You could depend upon the developer group to vote against anything that limited development and you could depend upon the environmentalist group to vote against most developments.
Then came a situation where a developer wanted to put some houses on a hill top. One of the developers joined the environmentalists in voting against the development. Oddly enough, the proposed development was not far from his house.
'Everybody' is an environmentalist when their quality of life is threatened. 'Everybody' is a capitalist when their financial well being is threatened.
Identifying a person's base background on the basis of only ten keystrokes seems to be stretching things. Though the article does mention all the additional information collected in order to make the determination.
The article does NOT mention what the people were typing. If they were doing a standard typing test, then you might be able to determine gender, culture and age. But if they were doing an online conversation, then you would have to factor in how well the person converts thoughts to words and words to typed text.
When your roof area covers twenty five percent or more of a lot and your aquifer depends upon rainwater recharge, collecting what is falling on your roof can have an impact. A lot would depend upon how much of the rainwater you capture makes it to the ground and how much evaporates.
If you grok the math enough to understand the difference, you would probably be working for vendors that create the hardware and software that everybody else uses. Or you would be doing software design and development for engineers or scientists. In either instance, you need to grok the math in order to write the software and design the hardware/firmware.
If you are just trying to learn enough to apply various algorithms, an afternoon or so would suffice. That or a cookbook on the 'best' algorithm for a given circumstance. It is kind of like driving a car. You don't have to know how the mechanical system works in order to get acceptable results. The results may not be as good as they could be though. You run into a trade off between the time spent finding the 'perfect' algorithm and the time it takes to get the job done.
It would be interesting to do a study on the costs of using the right algorithms versus the costs of using something that works. If it is something that is life and death, or you are dealing with big impacts in terms of time, money or other resources, you need the right algorithms. But if it is something relatively trivial, you need to ask yourself the question if the cost of implementing the 'right' algorithm is more than the cost of getting the job done quickly.
If you are doing basic bean counting software, you don't really need that much math. Calculus is overkill.
Heck, in some instances, you need to know how to interpret legal documents more than you need advanced math. I remember a case where I had to tweak an asset ledger system in order to help it meet IRS standards for depreciation after a change in ownership.
At the same time, if you are doing engineering or scientific programming, it can be extremely useful to know Advanced Calculus because that is what the engineers and scientists are using. You may be even better at the topic then they are because you have to translate the calculations into code.
I'd say that formally taught programmers may not have much experience with maintenance programming, especially with legacy systems that have been running for years. They are used to 'blank sheet' programming assignments that allow them to control the entire project from start to finish. They don't have to deal with code that has been modified dozens of times over the years, often without much documentation.
I got my professional start in programming doing maintenance programming under the supervision of a senior programmer who had spent years working with the systems as they evolved. While I had done some programming in college, all 'blank sheet' stuff, doing maintenance programming was much more educational. You had to make sure that things were done right, otherwise you could cause big, real world problems.
My initial programming experience predated the Design Pattern concept. At the same time, I knew about pattern language, the concept behind design patterns, because I had heard about the architectural version by Christopher Alexander.
Think of a pattern language as being a conceptual construct that does a specific job, be it an entry way for a house, a menu for an application or the splash page for a web site. Certain activities occur in that 'space' and if you know what those activities are, based on past history, you can effectively design for them. You might even have a set of solutions that you can copy and modify, which can save time and money.
Once the specs have been made, you can build it with the appropriate tools, be they construction materials or bits and bytes.
Thinking about it, I would say that good programmer and analysts were already looking for design patterns long before Design Patterns became formalized.
For several years, when people have pointed out that record snows are 'proof' that global climate change is NOT happening, I've mentioned that snow requires moisture and moisture requires warmth. The more warmth you have, the more moisture you have in the air and the more snow you can have when that moisture moves into an area where it is cold enough to get snow.
Oddly enough, in my area, after back to back seasons of heavy snow, including one record breaking season and one season where it was an inch short of the previous record, we have had a warm winter with minimal snow. For some reason the people that were using the record snows as 'proof' that global climate change is NOT happening are not talking about about what could be considered counter proof.
People really need to take a hard look at what they consider to be proof of their positions, no matter what position they take with regards to global climate change. And they also need to remember that it is NOT a binary man-made/not-man-made setup.
Ethics and estimating completion time: Sales 'suits' make promises that can't be met. The product goes out the door 'on time' but buggy. You then have to spend a lot of support time fixing things that shouldn't have been sent out broken. This takes time from future projects.
Employee loyalty and estimating completion time: The 'suits' want something done by a given date. Your development team is able to do it with a lot of unpaid overtime. They get the bonuses for having the product available. You get dinged for being ten percent over the budget that was never mentioned. Odds are your team won't do that again, so you have to add to the future estimates. Unfortunately, having done it once the 'suits' want you to do it again.
The environment and estimating completion time: (This is more applicable to physical construction.) You are doing construction on a hill next to a lake. If you do it right, you will spend a couple of days doing site prep to keep runoff from getting into the lake. You factor this into your construction cost/time estimate. The 'suits' want to save money or get the job done faster so they cut back on the site prep since it 'never' rains during the months that the site is vulnerable. They have you reduce the estimate by taking shortcuts. Material delays, change notices and a slightly early rain result in erosion and the silting of the lake. This silting could have been avoided if the proper site prep was done.
Customer loyalty and estimating completion time: This would be the customer side of the ethics example. The 'suits' promised you, the customer, the world and it wasn't delivered. You, the customer, complain to the development staff and point out the problems that need corrected. The development staff has to take time from their current projects to satisfy you. The development staff has to factor in this 'fixit' time in future estimates, reducing the amount of staff time available.
The middle class and estimating completion time: The 'suits', having created a number of problems within the organization, look for solutions via outsourcing to other countries. Your development team is cut, putting people on unemployment because of a glut in the IT employment market. (They are at risk of falling out of the middle class if they don't find work.) You have to factor in the efficiency and effectiveness of the outsourcing group, not knowing their true abilities. Your 'database' of in-house abilities and how long it takes to do things is no longer applicable. You may also need to factor in more time to define the project so that the outsourcing group can learn things that your development team already knew.
With a building you usually have VERY detailed plans that describe all of the parts that need to be constructed. These parts have physical components that are well defined and involve construction processes that have been around for decades if not centuries. This makes it possible to take advantage of 'construction cost' manuals and programs to come up with accurate estimates.
The process does fall apart when dealing with situations where materials or labor costs soar due to inflation or demand. It may also have problems when dealing with new technologies. And then you may run into the unexpected, like finding that your site survey is wrong and you need deeper foundations to counter the fact that most of your building is on mud and not bedrock.
When you think about it, the civil engineering estimates with detailed costing are done AFTER the design is complete.
When it comes to software, you frequently have to come up with the detailed project definition as part of your estimate. Then you have to guess at how long it will take to design and implement the project definition in an environment that changes quickly. Unlike building construction, many software 'construction' processes have only been around for a handful of years and they may only have a couple of more years of life in them.
To make things worse, the detailed project definition may change as your client gets a look at the prototypes you create. Since redoing software isn't as dramatic as tearing down and redoing part of a building, the end user may think that the new feature is easy to install.
It gets interesting.
Still, there is a section of the McConnell book that is intriguing. It discusses the difference between an estimate and a target. The following is a quote from the book:
"Tip # 2: When you are asked to provide an estimate, determine whether you're supposed to be estimating or figuring out how to hit a target."
Sometimes I think that the 'suits' will end up destroying the American economy in their pursuit of short term profits at the expense of things like ethics, employee loyalty, the environment, customer loyalty and the middle class.
I seem to recall a Buckminster Fuller making a comment about "a good definition being ninety percent of the solution to a problem." It would support the "Design is more valuable than code" viewpoint.
Getting that good definition front end can be a pain though.
Slashdot Mirror
Back in the 70's and 80's Senator William Proxmire (D - Wisconsin) handed out 'Golden Fleece' awards to groups that were doing things that he considered to be a waste of tax payers money.
I believe that one of the awards went to a group that was trying to reduce flatulence in cows.
It is interesting how said research has relevance today.
It is even more interesting that Proxmire represented a state that got a lot of price supports for the dairy industry.
Not all ag land is suitable for growing crops that are human consumable. That is one of the problems with the 'soy' argument.
Properly handled, a lot of this marginal ag land works well for grazing. Unfortunately, there are a lot of greedy types that overgraze the land and cause problems.
At the same time, there are a lot of crop growing types that abuse the land and cause problems too.
PS: I'm a Rand fan who reads Atlas Shrugged and The Fountainhead at least once a year.
Woot first point for the day. As usual idealists live in a 1 dimensional universe where they again fail to see the whole cost beyound the end of their nose.
He isn't on to something, and anyone that thinks this is a great idea is a stark raving idiot.
A: Treadmills don't far well outside. More roofed covered space. Nor to treadmills grow on trees.
B: Carbon footprint for the manfacturing of said treadmills
C: Additional feed for active cows now burning more calories. More waste from more feed too
D: Energy loss in conversion to heat from friction from transmission points
E: More wiring and cabling sucking down more copper from an already stressed raw material market. Ohms.... .Ohms.....
F: Who in their right mind thinks: taking solar energy and water and converting it into biomass
Then using millions of tons of fossil fuels to build machinery to develop and harvest biomass.
Feed said biomass to another animal
To use millions of tons of fossil fuels in manufacturing a kinetic engery transfomation device (treadmill)
To then power a machine to generate a fraction of the energy "THE SUN PUT OUT IN THE FIRST PLACE!?
Jebus Rice we are getting shit-eating stupid pretty damn fast when people think "Hey they're on to something..."
Narrow minded morons never looking past their own nose on what real costs are.
A. We're talking about ag quality treadmills, not human quality. Ag equipment tends to be designed to handle weather, dirt and manure while lasting a lot longer than treadmills meant for humans.
B. While manufacturing/maintaining the treadmills has a carbon footprint, so does getting power from non-treadmill generators to the milking machines.
C. Is that much additional feed needed? Farmers do have to consider feed costs in all the things they do. If they are lucky, they have their own feed sources or feed sources that are close by. I do recall one version of the article claiming that the cows wouldn't be any more active on the treadmill than they would be in the field.
D. All conversion systems have energy losses. To minimize these losses you need to get the generator as close to the end user as possible. In this case, the cow powered treadmill could be used to power the equipment used to milk the cow powering the treadmill, with an offset due to timing. (Batteries would likely be needed, or some sort of schedule that has X cows on the treadmills while Y cows are being milked.)
E. When considering the cost of copper, you also need to consider the demands that the solar industry and the wind power industry are putting on the market. Is the amount of material required for treadmills, with their reduced point to point losses, less than the amount of material needed to move power from solar and wind farms?
F. You might consider the treadmill idea to be more a case of trying to use an unused resource as opposed to creating a new power system. If the total value, financial and environmental, of the power generated exceeds the total cost, financial and environmental, of the equipment and other resources needed to generate that power, then it is a good idea. Note that these factors WILL vary location. Also note that the person promoting the idea wanted to reduce his dependency on fossil fuels. (In an area with lots of water and a good climate for growing hay, this could be done by using horses as opposed to tractors.)
General Comment: To be completely fair to all points of view, the cost/benefit analysis needs to consider all of the above and more before accepting or rejecting the idea.
You might want to differentiate between beef and dairy cows. A lot of grain is used to fatten up beef cattle for the market, after the cattle are fed on the range. This 'finishing' process is one of the reasons why there are stock yards.
Still, because producing milk takes a lot of protein, corn or other high protein substances are needed to supplement forage that comes in the form of hay or even grass if you are lucky enough to have a source of water. Grass or hay doesn't quite hack it.
Do note that using corn for ethanol is fairly wasteful and is one of the reasons that food prices have gone up. It is much better to use non-food vegetation for ethanol production.
Balancing all the inputs and outputs can get pretty complex, which is why ag majors were learning how to use linear programming based programs over three decades ago. Said programs allowed them to come up with cost effective grain-forage-supplement mixes for feeding beef and dairy cattle.
According to the source article I read, the treadmill seems to help cows reduce methane production. The idea is that cows that don't move around are more gassy than cows that move around.
I once worked for a software company where the owner said that programmers should not work more than forty hours a week, except in VERY rare emergencies. He based that on the observation that the programming done after the eight hour a day limit often required reworking, thus negating the gains achieved by overtime.
As far as my maximum effectiveness level, I could usually do about twenty hours hours of programming a week, including doing pseudo-code for some of the more complex bits of code. The rest of the time was spent in testing, tweaking and making sure that the new code works as desired, plus the standard overhead of keeping up the skill sets.
I consider the process of programming to be a job that requires a lot of brain sweat if you are trying for something that works and works well. After you reach a limit your mind needs a break, otherwise you end up with headaches or other stress related problems.
The roads like this are often called freeways or highways, and involve separating various types of traffic. Sometimes they are even special arterials with extra wide landscape areas surrounding them.
Unfortunately, traffic from these forms of road eventually mixes with residential, commercial and other land uses that involve people not in vehicles, which is where you need to slow things down. While you could continue separating vehicle traffic from other forms of traffic, it becomes extremely expensive. (Imagine having vehicle only tunnels to every home, business or other location. Or imagine prohibiting people from using roads unless they are in an approved vehicle.)
Fast isn't safe when vehicles and pedestrians interact.
Unless I'm making a long, cross country trip, the amount I pay in taxes for transportation bond issues is greater than the amount I pay in gas taxes on a yearly basis. And this is in a state with fairly high gas taxes.
That ignores the money that comes from the general fund and other sources like license fees. It also ignores the 'hidden' taxes for the transportation oriented services provided by the fire department, the police department and other services.
As more roundabouts are installed, more people will get used to them. I suspect that the traffic engineers anticipated the problem and figured that it would go away in time. The fact that there is confusion gets people to slow down, which shows that they do work, even when people aren't used to them.
While the roundabouts may or may not reduce the total number of accidents, I wouldn't be surprised if they reduced the severity of the accidents. Their geometry forces people to slow down so that it becomes a lot more difficult to have high speed t-bone accidents.
I get the feeling that a lot of people object to the idea of slowing down traffic in urban areas. After all, it keeps them from getting to their destination as fast as possible.
At the same time, these same people would probably welcome slower traffic IF they lived in and around these areas and were threatened by faster traffic. People are odd that way.
It reminds me of a situation where a city council had two major groups: developers and environmentalists. You could depend upon the developer group to vote against anything that limited development and you could depend upon the environmentalist group to vote against most developments.
Then came a situation where a developer wanted to put some houses on a hill top. One of the developers joined the environmentalists in voting against the development. Oddly enough, the proposed development was not far from his house.
'Everybody' is an environmentalist when their quality of life is threatened. 'Everybody' is a capitalist when their financial well being is threatened.
Identifying a person's base background on the basis of only ten keystrokes seems to be stretching things. Though the article does mention all the additional information collected in order to make the determination.
The article does NOT mention what the people were typing. If they were doing a standard typing test, then you might be able to determine gender, culture and age. But if they were doing an online conversation, then you would have to factor in how well the person converts thoughts to words and words to typed text.
When your roof area covers twenty five percent or more of a lot and your aquifer depends upon rainwater recharge, collecting what is falling on your roof can have an impact. A lot would depend upon how much of the rainwater you capture makes it to the ground and how much evaporates.
If you grok the math enough to understand the difference, you would probably be working for vendors that create the hardware and software that everybody else uses. Or you would be doing software design and development for engineers or scientists. In either instance, you need to grok the math in order to write the software and design the hardware/firmware.
If you are just trying to learn enough to apply various algorithms, an afternoon or so would suffice. That or a cookbook on the 'best' algorithm for a given circumstance. It is kind of like driving a car. You don't have to know how the mechanical system works in order to get acceptable results. The results may not be as good as they could be though. You run into a trade off between the time spent finding the 'perfect' algorithm and the time it takes to get the job done.
It would be interesting to do a study on the costs of using the right algorithms versus the costs of using something that works. If it is something that is life and death, or you are dealing with big impacts in terms of time, money or other resources, you need the right algorithms. But if it is something relatively trivial, you need to ask yourself the question if the cost of implementing the 'right' algorithm is more than the cost of getting the job done quickly.
If you are doing basic bean counting software, you don't really need that much math. Calculus is overkill.
Heck, in some instances, you need to know how to interpret legal documents more than you need advanced math. I remember a case where I had to tweak an asset ledger system in order to help it meet IRS standards for depreciation after a change in ownership.
At the same time, if you are doing engineering or scientific programming, it can be extremely useful to know Advanced Calculus because that is what the engineers and scientists are using. You may be even better at the topic then they are because you have to translate the calculations into code.
I'd say that formally taught programmers may not have much experience with maintenance programming, especially with legacy systems that have been running for years. They are used to 'blank sheet' programming assignments that allow them to control the entire project from start to finish. They don't have to deal with code that has been modified dozens of times over the years, often without much documentation.
I got my professional start in programming doing maintenance programming under the supervision of a senior programmer who had spent years working with the systems as they evolved. While I had done some programming in college, all 'blank sheet' stuff, doing maintenance programming was much more educational. You had to make sure that things were done right, otherwise you could cause big, real world problems.
My initial programming experience predated the Design Pattern concept. At the same time, I knew about pattern language, the concept behind design patterns, because I had heard about the architectural version by Christopher Alexander.
Think of a pattern language as being a conceptual construct that does a specific job, be it an entry way for a house, a menu for an application or the splash page for a web site. Certain activities occur in that 'space' and if you know what those activities are, based on past history, you can effectively design for them. You might even have a set of solutions that you can copy and modify, which can save time and money.
Once the specs have been made, you can build it with the appropriate tools, be they construction materials or bits and bytes.
Thinking about it, I would say that good programmer and analysts were already looking for design patterns long before Design Patterns became formalized.
Vindication!
For several years, when people have pointed out that record snows are 'proof' that global climate change is NOT happening, I've mentioned that snow requires moisture and moisture requires warmth. The more warmth you have, the more moisture you have in the air and the more snow you can have when that moisture moves into an area where it is cold enough to get snow.
Oddly enough, in my area, after back to back seasons of heavy snow, including one record breaking season and one season where it was an inch short of the previous record, we have had a warm winter with minimal snow. For some reason the people that were using the record snows as 'proof' that global climate change is NOT happening are not talking about about what could be considered counter proof.
People really need to take a hard look at what they consider to be proof of their positions, no matter what position they take with regards to global climate change. And they also need to remember that it is NOT a binary man-made/not-man-made setup.
The image credits even refer to Disney Enterprises, Inc.
For some reason this looks a lot like the House of the Future from Disneyland in the 1960's.
Ethics and estimating completion time: Sales 'suits' make promises that can't be met. The product goes out the door 'on time' but buggy. You then have to spend a lot of support time fixing things that shouldn't have been sent out broken. This takes time from future projects.
Employee loyalty and estimating completion time: The 'suits' want something done by a given date. Your development team is able to do it with a lot of unpaid overtime. They get the bonuses for having the product available. You get dinged for being ten percent over the budget that was never mentioned. Odds are your team won't do that again, so you have to add to the future estimates. Unfortunately, having done it once the 'suits' want you to do it again.
The environment and estimating completion time: (This is more applicable to physical construction.) You are doing construction on a hill next to a lake. If you do it right, you will spend a couple of days doing site prep to keep runoff from getting into the lake. You factor this into your construction cost/time estimate. The 'suits' want to save money or get the job done faster so they cut back on the site prep since it 'never' rains during the months that the site is vulnerable. They have you reduce the estimate by taking shortcuts. Material delays, change notices and a slightly early rain result in erosion and the silting of the lake. This silting could have been avoided if the proper site prep was done.
Customer loyalty and estimating completion time: This would be the customer side of the ethics example. The 'suits' promised you, the customer, the world and it wasn't delivered. You, the customer, complain to the development staff and point out the problems that need corrected. The development staff has to take time from their current projects to satisfy you. The development staff has to factor in this 'fixit' time in future estimates, reducing the amount of staff time available.
The middle class and estimating completion time: The 'suits', having created a number of problems within the organization, look for solutions via outsourcing to other countries. Your development team is cut, putting people on unemployment because of a glut in the IT employment market. (They are at risk of falling out of the middle class if they don't find work.) You have to factor in the efficiency and effectiveness of the outsourcing group, not knowing their true abilities. Your 'database' of in-house abilities and how long it takes to do things is no longer applicable. You may also need to factor in more time to define the project so that the outsourcing group can learn things that your development team already knew.
Think geodesic domes. He's the person that the form of carbon called 'bucky balls' is named after.
With a building you usually have VERY detailed plans that describe all of the parts that need to be constructed. These parts have physical components that are well defined and involve construction processes that have been around for decades if not centuries. This makes it possible to take advantage of 'construction cost' manuals and programs to come up with accurate estimates.
The process does fall apart when dealing with situations where materials or labor costs soar due to inflation or demand. It may also have problems when dealing with new technologies. And then you may run into the unexpected, like finding that your site survey is wrong and you need deeper foundations to counter the fact that most of your building is on mud and not bedrock.
When you think about it, the civil engineering estimates with detailed costing are done AFTER the design is complete.
When it comes to software, you frequently have to come up with the detailed project definition as part of your estimate. Then you have to guess at how long it will take to design and implement the project definition in an environment that changes quickly. Unlike building construction, many software 'construction' processes have only been around for a handful of years and they may only have a couple of more years of life in them.
To make things worse, the detailed project definition may change as your client gets a look at the prototypes you create. Since redoing software isn't as dramatic as tearing down and redoing part of a building, the end user may think that the new feature is easy to install.
It gets interesting.
Still, there is a section of the McConnell book that is intriguing. It discusses the difference between an estimate and a target. The following is a quote from the book:
"Tip # 2: When you are asked to provide an estimate, determine whether you're supposed to be estimating or figuring out how to hit a target."
Sometimes I think that the 'suits' will end up destroying the American economy in their pursuit of short term profits at the expense of things like ethics, employee loyalty, the environment, customer loyalty and the middle class.
I seem to recall a Buckminster Fuller making a comment about "a good definition being ninety percent of the solution to a problem." It would support the "Design is more valuable than code" viewpoint.
Getting that good definition front end can be a pain though.