tag:blogger.com,1999:blog-91156446058333841382024-03-13T21:16:17.380+01:00X de XavierUnos y ceros. A veces, en el orden adecuado.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-9115644605833384138.post-72785246669360712282008-12-09T16:11:00.002+01:002008-12-09T16:27:59.488+01:00Some notes about troubleshootingFrom <a href="http://www.whyprogramsfail.com/">Why Programs Fails: A Guide to Systematic Debugging</a>:<br /><br />Some terminology: from defects to failures<br /><ol><li>The programmer creates a <span style="font-weight: bold;">defect</span>.</li><li>The defect causes an <span style="font-weight: bold;">infection</span> (the program state differs from what the programmer intended)</li><li>The infection propagates</li><li>The infection causes a <span style="font-weight: bold;">failure</span> (an externally observable error in the program state).<br /></li></ol><br />Debugging can be decomposed into seven steps:<br /><blockquote><span style="font-weight: bold;">Track</span> the problem in the database<br /><span style="font-weight: bold;">Reproduce</span> the failure<br /><span style="font-weight: bold;">Automate</span> and simplify the test case<br /><span style="font-weight: bold;">Find</span> possible infection origins<br /><span style="font-weight: bold;">Focus</span> on the most likely origins:<br /><small> Known infections</small><br /><small> Causes in state, code, and input</small><br /><small> Anomalies</small><br /><small> Code smells</small><br /><span style="font-weight: bold;">Isolate</span> the infection chain<br /><span style="font-weight: bold;">Correct</span> the defect<br /></blockquote><br />Note the <span style="font-weight: bold;">TRAFFIC</span> mnemonic.<br /><br />Opinion ON:<br /><br />That's nice theory. Unfortunately, the complexity of IT has teached us that computers are non-deterministic beasts. The first thing that we do in case of a problem is restart the system, hope that the problem will go away, and be able to keep doing our job. And it often works.<br /><br />But we, software developers and support technicians, need to <span style="font-weight: bold;">un-learn our hide the symptoms urge</span>. If we suspect that there is some defect in the code (and trust this old software developer, you can be confindent that it very likely that there is one),<span style="font-weight: bold;"> our goal should always be to find the defect</span>, instead of changing things so that the defect is not executed or the infection does not end up causing a failure. Leaving that defect unfixed is very likely to cause pain in a future situation. À la <a href="http://www.pragprog.com/the-pragmatic-programmer/extracts/coincidence">programming by coincidence</a>.<br /><br />Some advice<br /><ul><li>avoid corrective actions before the issue is understood. Before the failing code is identified, you should <span style="font-weight: bold;">only use temporary corrective actions to help you frame the problem</span>. I'm guilty of having neglected this rule lots of times, and requested customers to just upgrade the code to see if the issue goes away.<br /></li><li>when possible, use tools that <span style="font-weight: bold;">minimize the infection propagation</span> (that, crash as soon as possible). On Windows, I was recently introduced to <a href="http://support.microsoft.com/kb/286470">pageheap</a> and I'm in love with. More on it another day.</li><li>defects come from source code:<span style="font-weight: bold;"> give support technicians access and knowledge to read the source code</span>. Support people and developers should change seats quite often.<br /></li></ul>-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com1tag:blogger.com,1999:blog-9115644605833384138.post-91512442517914867872008-12-03T09:45:00.000+01:002008-12-03T09:45:27.261+01:00MacacosAyer envié esto, en relación a mi actuación como enlace con el equipo de soporte de un producto del que no sé casi nada, en la que últimamente me limito a esperar órdenes de gente que está en una zona horaria equivocada:<br /><blockquote>Entiendo que el problema está en un punto en el que yo aporto poco más que un macaco al teclado</blockquote>Si hay suerte, hoy le pasaré los trastos a un chimpancé y podré dedicarme a cosas más interesantes. Deberé enseñarle a Pobre Chimpancé algunas cosas que he aprendido cuando he sido yo el que daba soporte:<br /><ul><li>que hay que ser paciente y no irritarse cuando te preguntan por séptima vez la misma cosa: no es nada personal.</li><li>que entre lo que digan los logs y lo que digas tú, soporte no dudará en creer lo que dicen los logs. Y te preguntarán una octava vez.<br /></li></ul>¡Oh, queridos ex-clientes! ¡Estos días he comprendido a qué torturas os he sometido durante tantos años!-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com4tag:blogger.com,1999:blog-9115644605833384138.post-37426488785599259172008-03-04T23:37:00.005+01:002008-03-05T00:24:13.796+01:00Debugging Emergency Kit<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_T679aggANRU/R83ParVxhAI/AAAAAAAAAD0/OLlZmbRrMXs/s1600-h/RubberDuckAndDebugging.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_T679aggANRU/R83ParVxhAI/AAAAAAAAAD0/OLlZmbRrMXs/s320/RubberDuckAndDebugging.png" alt="Debugging and the scientific method" id="BLOGGER_PHOTO_ID_5174019604136166402" border="0" /></a><br />The image above is the hand-out of the last talk I gave. <a href="http://compsci.ca/blog/rubber-ducks-help-best-with-computer-science/">Rubber ducks have long been known as one of the most effective debugging devices</a> [1].<br /><br />Very often, while debugging, you *know* that you are almost there. The problem is that, before you notice, the morning has gone by with you being "almost there". If you don't really get there after a couple of quick and dirty iterations and want to avoid wasting a morning "almost there", it is very useful to make explicit the steps that everyone takes while debugging: enter your notebook and the scientific method (quoting from <a href="http://www.st.cs.uni-sb.de/zeller/">Andreas Zeller</a>'s <a href="http://www.whyprogramsfail.com/">Why Programs Fail: A Guide to Systematic Debugging</a>)<br /><ol><li>Observe a failure</li><li>Invent a hypothesis consistent with the observations</li><li>Use the hypothesis to make predictions</li><li>Test the hypothesis by experiments and further observations<ul><li>If the experiment satisfies the predictions, refine the hypothesis</li><li>If the experiment does not satisfy the hypothesis, create an alternate hypothesis<br /></li></ul></li><li>Repeat steps 3 and 4 until the hypothesis can no longer be refined<br /></li></ol>Keeping a written track of the steps is the key here. The advice is quite obvious, but we often forget about obvious things that work very well [2].<br /><br /><span style="font-size:85%;">[1] This is not the only surprising ability of rubber ducks: <a href="http://en.wikipedia.org/wiki/Rubber_duck#Oceanography">http://en.wikipedia.org/wiki/Rubber_duck#Oceanography</a><br />[2] I'm writing this post after a most ineffective "almost there" afternoon</span>-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-20975738622887712362007-05-30T22:36:00.000+01:002007-05-30T22:28:48.780+01:00¿Me sobran hijos?<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_T679aggANRU/Rl3oJ9qTlLI/AAAAAAAAACU/z1xBRqNJOCQ/s1600-h/trasme.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp1.blogger.com/_T679aggANRU/Rl3oJ9qTlLI/AAAAAAAAACU/z1xBRqNJOCQ/s400/trasme.png" alt="" id="BLOGGER_PHOTO_ID_5070464013357520050" border="0" /></a><br />De acuerdo, Trasme: me voy con <a href="https://balearia.net/">Balearia</a>, que nos quiere a todos.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com1tag:blogger.com,1999:blog-9115644605833384138.post-15240940549916005812007-03-13T10:01:00.001+01:002008-10-08T23:48:50.916+01:00On using dead chickens for problem determination<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.flickr.com/photos/input/114134044/"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer;" src="http://farm1.static.flickr.com/34/114134044_bd962873e5_m_d.jpg" alt="" border="0" /></a>My friend <a href="http://lucalvago.blogspot.com/">Luis</a> comes back to the office in state of shock. He has been at a client's, along with two people from two other supplier companies that will go unnamed.<br /><br />They are trying to determine why an application with code from the three parties is crashing. Luis is amazed while the experts invoke the crashing code while turning over their heads a dead chicken clockwise, check the output of filemon and regmon, repeat the process turning the chicken counter-clockwise, and perform another half an hour of equally insightful tests. Based on the evidence collected while changing the chicken's turning speed, the experts conclude that's IBM's code fault and they want to rush to tell the customer about it.<br /><br />Luis takes a while to digest these new problem determination techniques, and, when he is able to recover his ability to speak, suggests taking a look at the logs from <a href="http://support.microsoft.com/kb/308538">Doctor Watson</a>; the experts are amazed by the tool; the logs show that the dead-chicken-based finger pointing is very unlikely to be right.<br /><br />The experts grab their huge flemon and regmon outputs, the drwtson32 logs and their dead chickens and leave. It takes us a while to get Luis back to unpuzzled mode.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.retrobill.com/store.htm#chicken"><img style="margin: 0pt 10px 10px 0pt; cursor: pointer;" src="http://www.retrobill.com/images/ventura1.jpg" alt="" border="0" /></a>-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com1