Or the constant roar of compressor stations. They use aircraft turbine engines to run the compressors for natural gas pipeline. Or sex with drunken meth addled rig hands. Or fumes from diesel engines. Or fumes from burning oil pits. Etc.
Oil and gas exploration is a dirty and nasty business. The sooner we can replace it with something cleaner the better.
That is the real problem. The entire basis for the corporate system is avoidance of responsibility. Maximize profits at any cost, even human life. And bad emission controls do threaten human life, see the killer smogs in London in the 50's or in China today. Look at the BP oil spill, the Piper Alpha, or Bhopal India and not a single C level manager or member of the BOD was held responsible, despite the fact that when things go right they get bonuses.
Until we hold executive officers, whose title comes from the word "to execute" as in to make happen, or members of the BOD are personally held civilly and/or criminally responsible then nothing will really change.
It lost it in the 90's. Now Portland has been destroyed. Austin and Colorado are gone as well. Boston, San Jose and area also were lost long ago. We don't know if it is airborne, blood borne, or due to some weird radiation a space probe returned.
Like an Anarcho-Syndicated Commune? With decisions decided by a simple majority vote in the case of internal affairs but 2/3rds for more serious matters?
How did they randomize the subjects? They also first picked the subjects before selecting the hypothesis which I find odd. Did they skew the hypothesis to meet the population?
What is the definition of DevOps? How cvan you discriminate between DevOps and no DevOps environments? I assume it is a spectrum, how is that controlled? What was the control in the study?
If you look at it it is essentially 3 aircraft. Different airframes, avionics, wing geometries etc. VTOL, regular runway, and carrier capability. The last it was tried was with the F-4 and it failed in it's original goals of interchangeable parts and sate of the art tech as well ( the expensive Sparrow missile dod not work correctly for about 10 years).
Buzz word compliant with a good brand image. All that is required is some market share growth to maximize synergistic leverage of crowd sourced BYOD distributed 24/7 virtualized cloud based components.
That's sort of the point. There will be unforeseen problems, mistakes, etc and recovery from those will be almost impossible. Even the James town colony died off and it was in a much more hospitable climate.
Amazon Flex won't release their contract. My email exchange with them resulted in this reply:
"When you come to our onboarding session and download the app, you can review the Terms of Service. "
Why should I make any sort of commitment before seeing the contract? What if I have to sign an NDA so I canot share the information? They could easily post it on their website, after all they are a tech company. I feel like they do not want to deal on a level playing field with me.
"Human knowledge is doubling at about every three years"
Knowledge or information. There is a difference.
" If you want great trumpet players you must train many thousands of trumpet players for several years for the great ones to rise from the mundane players"
How do we do that? Music is usually optional, trumpet playing even more so.
"If we train 30 million young people to very high levels of programming we will see programming super stars emerge"
Once again, how do we do that? What is the definition of "very high level"?
"There is no way to send reliable messages from afar to such war weapons"
Yes there is. We currently do it. We even control Mars explorers remotely and have encryption algorithms which are nigh impossible to crack in real time.
In reading these comments the phrase "Giving estimates without a detailed design is bad" pops up in one form or another. Basically that is asking for a waterfall. I am somewhat uneasy how often it has appeared even in this day and age. Here are my observations on the topic:
1) Forget good requirements, no one has them. No one knows what exactly the software will do at the beginning of the process. One thing I am certain of is that in about 18 months, if you are competent and lucky, you will start to have a good piece of software.
2) Instead think of "Initial Requirements". That the best you can do. Customer has a problem to solve, start solving the problem.
3) As you solve the problem new requirements appear. This is due to two factors, the customer does not know what they do not know until an analysis is done, analysis is often the biggest pay off of a software project in my opinion[1], and the customer starts to see possibilities. Once you give customers new capabilities they often use those ideas to springboard more features. Often too software requires a review of business process which shed light on how a business is *actually* run, not how management *thinks* it is run. This will cause requirements shift.
4) Work more on your customers rhythm, not yours. Don't roll out major changes in December if your client is a retailer for example.
5) Keep the customer happy by giving them continual improvements in functionality. Lots of little releases to throw them a bone and to get feedback since requirements always will shift. Stay close to the end user and listen to them.
6) Good software is a living breathing thing. Expect to live with it for decades and continually improve it. It is never really done.
The core of Agile gets some of this right. Though I am worried about a natural impedance when projects become very globally distributed and in terms of Agile scaling.
[1]Anecdote. I was working on a database development project for a mid-sized company with 2 main offices in two cities 300km apart. I began by learning the business processes and by diagramming them out. The principals of the company were flabbergasted when I showed them my diagram. The two offices were doing things very differently. We spent the next 2 months realigning core business processes before writing any code. It was actually fun.
Part of the difference is that a house is a tangible object. You can see it, feel it, smell it, etc. Software is not, it is largely an intellectual excesses. That makes it hard even for good developers. I have even used a house metaphor at times when talking to customers as in "you're asking us to tile the second floor bathroom before we have the foundation in place".
Or the constant roar of compressor stations. They use aircraft turbine engines to run the compressors for natural gas pipeline. Or sex with drunken meth addled rig hands. Or fumes from diesel engines. Or fumes from burning oil pits. Etc.
Oil and gas exploration is a dirty and nasty business. The sooner we can replace it with something cleaner the better.
Ummm yes. And how many builders resisted moving to gas and electric?
Pittsburgh, Cleveland, Iowa, etc. In other words quirky out of the way places looked down upon by people. Like Seattle and Austin used to be.
That is the real problem. The entire basis for the corporate system is avoidance of responsibility. Maximize profits at any cost, even human life. And bad emission controls do threaten human life, see the killer smogs in London in the 50's or in China today. Look at the BP oil spill, the Piper Alpha, or Bhopal India and not a single C level manager or member of the BOD was held responsible, despite the fact that when things go right they get bonuses.
Until we hold executive officers, whose title comes from the word "to execute" as in to make happen, or members of the BOD are personally held civilly and/or criminally responsible then nothing will really change.
It lost it in the 90's. Now Portland has been destroyed. Austin and Colorado are gone as well. Boston, San Jose and area also were lost long ago. We don't know if it is airborne, blood borne, or due to some weird radiation a space probe returned.
We just don't know.
If they were really engineers they would be civilly and legally responsible and would have to carry malpractice insurance.
Like an Anarcho-Syndicated Commune? With decisions decided by a simple majority vote in the case of internal affairs but 2/3rds for more serious matters?
https://www.youtube.com/watch?...
How did they randomize the subjects? They also first picked the subjects before selecting the hypothesis which I find odd. Did they skew the hypothesis to meet the population?
What is the definition of DevOps? How cvan you discriminate between DevOps and no DevOps environments? I assume it is a spectrum, how is that controlled? What was the control in the study?
Not to mention he probably hose d up the lives of any man interested in dating those 9 women. C'mon, don't ruin it for the next guy.
Yes. They were looking to hurt people just because they could and could get away with it.
If you look at it it is essentially 3 aircraft. Different airframes, avionics, wing geometries etc. VTOL, regular runway, and carrier capability. The last it was tried was with the F-4 and it failed in it's original goals of interchangeable parts and sate of the art tech as well ( the expensive Sparrow missile dod not work correctly for about 10 years).
A total fuck up if there was one.
No you are wrong. I have met some evil people in my life.
In the oil patch we referred to snow as "okie" dust. You sprinkle some around and all the Okies and Texans disappear.
Is he saving Antarctica for retirement? ;)
Buzz word compliant with a good brand image. All that is required is some market share growth to maximize synergistic leverage of crowd sourced BYOD distributed 24/7 virtualized cloud based components.
That's sort of the point. There will be unforeseen problems, mistakes, etc and recovery from those will be almost impossible. Even the James town colony died off and it was in a much more hospitable climate.
Amazon Flex won't release their contract. My email exchange with them resulted in this reply:
"When you come to our onboarding session and download the app, you can review the Terms of Service. "
Why should I make any sort of commitment before seeing the contract? What if I have to sign an NDA so I canot share the information? They could easily post it on their website, after all they are a tech company. I feel like they do not want to deal on a level playing field with me.
I emailed them and here was their response.
"When you come to our onboarding session and download the app, you can review the Terms of Service. "
Not good if you want to study it before making a commitment. Also, if you down load it what if they force you into an NDA?
That's "Interchangeable Biological Units" you insensitive clod!
I emailed them asking to see their contract.
I'm sure chefs use bash and Python everyday. Or perhaps chefs prefer "Puppet".
(Now let's see who get the jokes :)
"Human knowledge is doubling at about every three years"
Knowledge or information. There is a difference.
" If you want great trumpet players you must train many thousands of trumpet players for several years for the great ones to rise from the mundane players"
How do we do that? Music is usually optional, trumpet playing even more so.
"If we train 30 million young people to very high levels of programming we will see programming super stars emerge"
Once again, how do we do that? What is the definition of "very high level"?
"There is no way to send reliable messages from afar to such war weapons"
Yes there is. We currently do it. We even control Mars explorers remotely and have encryption algorithms which are nigh impossible to crack in real time.
You have no clue as to what you are saying.
The teachers will have to create story problems which require coding.
In reading these comments the phrase "Giving estimates without a detailed design is bad" pops up in one form or another. Basically that is asking for a waterfall. I am somewhat uneasy how often it has appeared even in this day and age. Here are my observations on the topic:
1) Forget good requirements, no one has them. No one knows what exactly the software will do at the beginning of the process. One thing I am certain of is that in about 18 months, if you are competent and lucky, you will start to have a good piece of software.
2) Instead think of "Initial Requirements". That the best you can do. Customer has a problem to solve, start solving the problem.
3) As you solve the problem new requirements appear. This is due to two factors, the customer does not know what they do not know until an analysis is done, analysis is often the biggest pay off of a software project in my opinion[1], and the customer starts to see possibilities. Once you give customers new capabilities they often use those ideas to springboard more features. Often too software requires a review of business process which shed light on how a business is *actually* run, not how management *thinks* it is run. This will cause requirements shift.
4) Work more on your customers rhythm, not yours. Don't roll out major changes in December if your client is a retailer for example.
5) Keep the customer happy by giving them continual improvements in functionality. Lots of little releases to throw them a bone and to get feedback since requirements always will shift. Stay close to the end user and listen to them.
6) Good software is a living breathing thing. Expect to live with it for decades and continually improve it. It is never really done.
The core of Agile gets some of this right. Though I am worried about a natural impedance when projects become very globally distributed and in terms of Agile scaling.
[1]Anecdote. I was working on a database development project for a mid-sized company with 2 main offices in two cities 300km apart. I began by learning the business processes and by diagramming them out. The principals of the company were flabbergasted when I showed them my diagram. The two offices were doing things very differently. We spent the next 2 months realigning core business processes before writing any code. It was actually fun.
Part of the difference is that a house is a tangible object. You can see it, feel it, smell it, etc. Software is not, it is largely an intellectual excesses. That makes it hard even for good developers. I have even used a house metaphor at times when talking to customers as in "you're asking us to tile the second floor bathroom before we have the foundation in place".