<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.11" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Fix It So It Stays Fixed: An Example</title>
	<link>http://kylecordes.com/2007/10/01/stay-fixed-disk-space/</link>
	<description>Kyle Cordes's Software Site</description>
	<pubDate>Wed, 20 Aug 2008 08:42:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.11</generator>

	<item>
		<title>by: Alex Miller</title>
		<link>http://kylecordes.com/2007/10/01/stay-fixed-disk-space/#comment-11845</link>
		<pubDate>Tue, 02 Oct 2007 19:54:48 +0000</pubDate>
		<guid>http://kylecordes.com/2007/10/01/stay-fixed-disk-space/#comment-11845</guid>
					<description>Agreed, this is an important meta-idea.  In fact, I think the level to which a team (or individual) grasps this and goes after it is probably a good measure of how successful they will be in maintaining the system over time.  

When I was at NFJS this weekend, I saw a talk from Michael Nygard on "designing for ops".  One thing that resonated with me is that when they see support problems, they want the novelty of those problems to be high.  

Seems to me there are multiple choices when you face a recurring operations problem: 
1) develop manual response procedure
2) develop automated response procedure 
3) develop an environmental fix (tweaking)
4) develop a temporary patch (something to tide you over till next release)
5) develop a permanent fix

These are ordered in ways closer to "fix it forever".  The correct choice is usually a mix between urgency, expediency, and difficulty of course.</description>
		<content:encoded><![CDATA[<p>Agreed, this is an important meta-idea.  In fact, I think the level to which a team (or individual) grasps this and goes after it is probably a good measure of how successful they will be in maintaining the system over time.  </p>
<p>When I was at NFJS this weekend, I saw a talk from Michael Nygard on &#8220;designing for ops&#8221;.  One thing that resonated with me is that when they see support problems, they want the novelty of those problems to be high.  </p>
<p>Seems to me there are multiple choices when you face a recurring operations problem:<br />
1) develop manual response procedure<br />
2) develop automated response procedure<br />
3) develop an environmental fix (tweaking)<br />
4) develop a temporary patch (something to tide you over till next release)<br />
5) develop a permanent fix</p>
<p>These are ordered in ways closer to &#8220;fix it forever&#8221;.  The correct choice is usually a mix between urgency, expediency, and difficulty of course.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
