|
Related to the below.
You cannot eliminate risk.
Doing something that carries risk is OK.
You need to know what the risk is.
You need to know what to do should something go wrong.
At some point you just have to bloody well do something.
Some places spend so much time and money trying to manage / eliminate risk that they end up either moving so slowly as to retard themselves or do nothing at all.
They spend so much time of so many people trying to ensure nothing will go wrong that the cost of ensuring nothing goes wrong far outweighs the cost of something going wrong.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
I always like the A Team quote about the best plans are those that can be changed. (At least I thinks its the A Team....)
Anyway, means you bring the risk to the front of the process, and go ahead with what you know with the proviso that things can change as new data comes in.
That's the best way to attack any project, be it building a bridge or a chunk of code.
|
|
|
|
|
Even if you are not in the A team, you should know that the first victim after contact with the enemy always is the plan. Strategists go sit on that hill over there and watch if you like, tacticians take over!
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
...and then the Accountants decide it's too expensive to do because it has cost so much to get to the point where you decide you can do it, the project itself will clearly take forever. 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Or, as I tagline a lot of my email:
Aut viam inveniam aut faciam - Carpe Diem!
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
chriselst wrote: You cannot eliminate risk.
NASA has a lot of resources, and they test more than the average company. Even they blow up a rocket by accident.
Dung happens.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Even they blow up a rocket by accident.
That may have something to do with having everything built by the lowest bidder! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
..yes, the argument against work paid for by the government. NASA proves the opposite; fact that not every rocket explodes shows that they not just select the cheapest.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Or crash it into a planet.
|
|
|
|
|
this is Murphy's Law. If everything is flawless, you can't advence. Perhaps our life is created by a bad mistake like mutation.
Every irregularity creates own regularity.
|
|
|
|
|
Some project management frameworks recommend that Tasks with the highest risk be performed as early as possible in the project.
In other words, if you are going to fail, fail early before it costs too much.
You can then decide whether to kill the project, or find an alternate way of accomplishing the task that failed before you've invested a lot of work into the bad path.
|
|
|
|
|
Mike Tyson:
Quote: "Everybody has a plan until they get punched in the mouth."
Me:
It's great to plan, great to know the risks, great to plan to mitigate those risks... then shït happens.
|
|
|
|
|
All very well to argue about risk management and apparently timid actions, but when it involves peoples' jobs and the consequences of a bad decision is personally telling 20 people they are being laid off indefinitely your perspective may change. And if you happen to be one of those 20 people called into the conference room on a Monday morning that risky management decision suddenly isn't bold but utterly stupid.
The civil engineer who designed the Tacoma Narrows bridge knew about wind loading but took the risk it wouldn't matter. The calculations were Engineering 101, very basic but he didn't bother. The classic pictures of the bridge tearing itself apart illustrates how bold and daring he was. Would you drive over one of his bridges on the way to work every day, knowing he didn't bother to make sure nothing would go wrong?
|
|
|
|
|
Very nice.
But to treat every thing you do with that level of risk management is also utterly stupid.
If you spend months of half a dozen people's time testing a system when the worst that could happen is an hour when twenty staff would have to write what they were doing on paper then type it into the system when it becomes available again does that make sense?
That was my point.
Your risk management has to be proportional to what you are doing.
If the cost of trying to stop anything going wrong far outweighs the cost of the worst that could happen, why bother?
No-one's job at stake, no lives at stake, no chance of injury. A bit of down time, maybe a small (£20) fine or two.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
*IF* the calculations for aeroelasticity (the actual cause of the disaster) were "Engineering 101", as you claim, then the blame does not rest solely on the hands of the civil engineer who designed the bridge (Leon Moisseiff, in case you are interested) but in the engineering team that accepted his design and the inspectors charged with ensuring that the work was done correctly. (The bridge did NOT gain the nickname "Galloping Gertie" was not given after completion - it was given by the construction crew.)
Aeroelastic models only came into existence in the twenties and thirties, and surprise, surprise, they came from the new science of aerodynamics, with research being almost totally applied to the building of airplanes.
Much as you would like, aeroelasticity did not become part of "Engineering 101" until after the Tacoma Narrows fiasco, and that bridge collapse was one of if not the prime motivator for aeroelasticity becoming part of Engineering 101.
As for "Would you drive over one of his bridges on the way to work every day, knowing he didn't bother to make sure nothing would go wrong?", I really hate to quote Donald Rumsfeld, but it is appropriate. He said, "Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones."
Discovering those "unknown unknowns" is the history of engineering
|
|
|
|
|
chriselst wrote: You cannot eliminate risk.
Whoa dude, don't let any upper manager hear you talk like that.
CLM - Career Limiting Move.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
but then some managers had some meetings and all danger of achieving something has been pushed back a week.
Add your own favourite swear words.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
Yippie ki-yay mother-elephanter?
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
den2k88 wrote: If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
I like it! This could be done as long as je/jne/jl/jle and all of the other branch instructions are not counted 
"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak
|
|
|
|
|
|
Yes, all one really needs is the following:
stc
jc {your_label_to_JMP_to}
"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak
|
|
|
|
|
We need to put together a cross-department working group to come up with a strategy to identify any underlying headwinds in our execution pipeline. 
|
|
|
|
|
Duncan Edwards Jones wrote: We need to put together a cross-department working group
We're above that: every working group in each department is already cross.
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
Now that was funny. I can go to bed now. 
|
|
|
|
|
Duncan Edwards Jones wrote: put together a cross-department working group to come up with a strategy to identify any underlying headwinds in our execution pipeline
How did you get our company's mission statement? It took us a month long offsite meeting to come up with that and it is only printed on our (non-electronic) whiteboard. Are you able to hack whiteboards?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
