<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://citconf.com/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=MrPi</id>
	<title>CitconWiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://citconf.com/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=MrPi"/>
	<link rel="alternate" type="text/html" href="https://citconf.com/wiki/index.php?title=Special:Contributions/MrPi"/>
	<updated>2026-06-04T00:37:19Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.43.8</generator>
	<entry>
		<id>https://citconf.com/wiki/index.php?title=Risk_management_and_voodoo_charms&amp;diff=14719</id>
		<title>Risk management and voodoo charms</title>
		<link rel="alternate" type="text/html" href="https://citconf.com/wiki/index.php?title=Risk_management_and_voodoo_charms&amp;diff=14719"/>
		<updated>2012-10-20T15:52:02Z</updated>

		<summary type="html">&lt;p&gt;MrPi: Created page with &amp;quot;Moderated by: Jtf  Voodoo charm - &amp;quot;Lets keep an eye on it!&amp;quot;, but ignoring the actual responsibility  Lets monitor it in production! How do we actually do that? You should have...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Moderated by: Jtf&lt;br /&gt;
&lt;br /&gt;
Voodoo charm - &amp;quot;Lets keep an eye on it!&amp;quot;, but ignoring the actual responsibility&lt;br /&gt;
&lt;br /&gt;
Lets monitor it in production! How do we actually do that?&lt;br /&gt;
You should have a plan. How? When? Where?&lt;br /&gt;
It seems like we often identify problems, agreeing that it is a problem and that we need to monitor it, but nothing is done. How do we prevent this?&lt;br /&gt;
&amp;quot;Should&amp;quot; or &amp;quot;I intend to&amp;quot; are dangerous words. You get immediate gratification and feel you really do not have to act on what you intended to do.&lt;br /&gt;
We need tools and formal techniques to actually do what we are thinking about doing.&lt;br /&gt;
It&#039;s all about the definition of done. A programmers version of &amp;quot;done&amp;quot; probably means &amp;quot;the happy case works and the first iteration of tests are green&amp;quot;, which does not mean that the feature actually Works. You have to look at the whole system, _including_ the non functional requirements.&lt;br /&gt;
The non-functional requirements needs to be tested/monitored as well. But how do we find out what tests/monitoring specs we need to have/add?&lt;br /&gt;
Draw a map of the entire system, the ENTIRE system. Think about the dependencies (arrows) between components and go through all of them. &amp;quot;What if this part goes down, how do we know?&amp;quot; Will an email be sent? What if the email server is down? This is called failure analysis. From this you have to think about the impact of these failures; Impact Analysis. When you have identified the impact you have to think about the risk; risk analysis. From the risk analysis you can identify actual business cases which can amount to use cases/stories.&lt;br /&gt;
&lt;br /&gt;
Failure Analysis -&amp;gt; Impact Analysis -&amp;gt; Risk Analysis -&amp;gt; Business Case&lt;br /&gt;
&lt;br /&gt;
Usually we are not good at thinking about the whole system and thinking about risks outside of the code base.&lt;br /&gt;
&lt;br /&gt;
Do you want to be proactive or reactive with this? Going through a failure analysis BEFORE you have a problem will help you avoid problems.&lt;br /&gt;
&lt;br /&gt;
Detection&lt;br /&gt;
Mitigation&lt;br /&gt;
Prevention&lt;br /&gt;
&lt;br /&gt;
SPIN Selling - how to sell change;&lt;br /&gt;
Situation&lt;br /&gt;
Problem&lt;br /&gt;
Implications&lt;br /&gt;
Needs analysis&lt;br /&gt;
&lt;br /&gt;
Why does it work? Because you need to talk to people about specific cases and collaborate.&lt;/div&gt;</summary>
		<author><name>MrPi</name></author>
	</entry>
</feed>