<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Just Enough vs. Just In Case</title>
	<atom:link href="http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/</link>
	<description>Software, Agile Process and Security</description>
	<lastBuildDate>Wed, 11 Aug 2010 03:38:47 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mediocre-Ninja.blogSpot.com</title>
		<link>http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/comment-page-1/#comment-4651</link>
		<dc:creator>Mediocre-Ninja.blogSpot.com</dc:creator>
		<pubDate>Wed, 11 Aug 2010 03:38:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.adeptechllc.com/?p=273#comment-4651</guid>
		<description>There should have been &quot;YAGNI&quot; around the coding standard/convention to remind ppl of the &quot;just enough&quot; :)</description>
		<content:encoded><![CDATA[<p>There should have been &#8220;YAGNI&#8221; around the coding standard/convention to remind ppl of the &#8220;just enough&#8221; <img src='http://www.adeptechllc.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Keith McMillan</title>
		<link>http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/comment-page-1/#comment-4637</link>
		<dc:creator>Keith McMillan</dc:creator>
		<pubDate>Sat, 06 Mar 2010 22:30:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.adeptechllc.com/?p=273#comment-4637</guid>
		<description>Hello Lev,

I&#039;m afraid we&#039;re going to have to disagree on this. I used to be a proponent of modeling every use case/user story, and then keeping the model up to date, so we knew the design of every use case, which classes it involved, and what methods.  Over time, we had to let go of updating all those models after someone changed something, due to the pressure of delivering more to the customer, and a funny thing happened: it just didn&#039;t matter that the models weren&#039;t up to date: nobody used them.

Sure, it&#039;s a good idea to make sure that the features you want are represented as user stories, or use cases, to make sure you don&#039;t forget something important, but that can be done in a very lightweight way (keeping track of themes or epics, and then making sure there are stories for them, for instance), and that&#039;s not what I mean by complete traceability.  Traceability to me is being able to refer to a detailed model for the story (typically class and sequence diagrams), and knowing that the model is correct.  That means that someone kept it up to date, or rather that &lt;i&gt;everyone&lt;/i&gt; who worked on the system did.

The value of producing a model for a story or a use case is in thinking about how you&#039;re going to deal with the requirements, and that can be done at a whiteboard. If it&#039;s put into a formal modeling tool, in my experience it&#039;s seldom referred to afterward, sometimes because it&#039;s no longer correct (because nobody updated it), sometimes because it doesn&#039;t cover the right level of detail in order to be useful, and sometimes because it&#039;s just easier to read the code.

In my experience, which is considerable after over a decade working for large companies as a consultant, here&#039;s only one that got any real value from complete traceability, and they were filing FDA paperwork for medical devices, so it was a requirement for them.

I appreciate your comments, even if we disagree,

Keith</description>
		<content:encoded><![CDATA[<p>Hello Lev,</p>
<p>I&#8217;m afraid we&#8217;re going to have to disagree on this. I used to be a proponent of modeling every use case/user story, and then keeping the model up to date, so we knew the design of every use case, which classes it involved, and what methods.  Over time, we had to let go of updating all those models after someone changed something, due to the pressure of delivering more to the customer, and a funny thing happened: it just didn&#8217;t matter that the models weren&#8217;t up to date: nobody used them.</p>
<p>Sure, it&#8217;s a good idea to make sure that the features you want are represented as user stories, or use cases, to make sure you don&#8217;t forget something important, but that can be done in a very lightweight way (keeping track of themes or epics, and then making sure there are stories for them, for instance), and that&#8217;s not what I mean by complete traceability.  Traceability to me is being able to refer to a detailed model for the story (typically class and sequence diagrams), and knowing that the model is correct.  That means that someone kept it up to date, or rather that <i>everyone</i> who worked on the system did.</p>
<p>The value of producing a model for a story or a use case is in thinking about how you&#8217;re going to deal with the requirements, and that can be done at a whiteboard. If it&#8217;s put into a formal modeling tool, in my experience it&#8217;s seldom referred to afterward, sometimes because it&#8217;s no longer correct (because nobody updated it), sometimes because it doesn&#8217;t cover the right level of detail in order to be useful, and sometimes because it&#8217;s just easier to read the code.</p>
<p>In my experience, which is considerable after over a decade working for large companies as a consultant, here&#8217;s only one that got any real value from complete traceability, and they were filing FDA paperwork for medical devices, so it was a requirement for them.</p>
<p>I appreciate your comments, even if we disagree,</p>
<p>Keith</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lev Ayzner</title>
		<link>http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/comment-page-1/#comment-4636</link>
		<dc:creator>Lev Ayzner</dc:creator>
		<pubDate>Sat, 06 Mar 2010 21:54:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.adeptechllc.com/?p=273#comment-4636</guid>
		<description>While I agree with &quot;just enough&quot; mentality in general, I may not agree with traceability is &quot;incredibly expensive and time consuming to produce, and to maintain&quot;.

Knowing what is the right thing to do is necessary but not sufficient. Necessary and sufficient is doing the right thing the right way... Then, it may provide &quot;good enough&quot; value. Hard to believe that no one has got any positive experience with traceability.

Thanks,
LevA</description>
		<content:encoded><![CDATA[<p>While I agree with &#8220;just enough&#8221; mentality in general, I may not agree with traceability is &#8220;incredibly expensive and time consuming to produce, and to maintain&#8221;.</p>
<p>Knowing what is the right thing to do is necessary but not sufficient. Necessary and sufficient is doing the right thing the right way&#8230; Then, it may provide &#8220;good enough&#8221; value. Hard to believe that no one has got any positive experience with traceability.</p>
<p>Thanks,<br />
LevA</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan</title>
		<link>http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/comment-page-1/#comment-4635</link>
		<dc:creator>Ryan</dc:creator>
		<pubDate>Thu, 04 Mar 2010 21:34:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.adeptechllc.com/?p=273#comment-4635</guid>
		<description>I agree with your post, Keith, but I think there is another complication here. Sometimes the &quot;just in case&quot; is hidden behind a well constructed facade backed by well thought out (but usually quite convoluted) theories and ideas. It requires digging and wading through the facade in order to realize that what is actually behind there is simply a &quot;just in case&quot; or sometimes a nice CYA. Unfortunately, tearing down the facade usually takes a lot of time and effort.</description>
		<content:encoded><![CDATA[<p>I agree with your post, Keith, but I think there is another complication here. Sometimes the &#8220;just in case&#8221; is hidden behind a well constructed facade backed by well thought out (but usually quite convoluted) theories and ideas. It requires digging and wading through the facade in order to realize that what is actually behind there is simply a &#8220;just in case&#8221; or sometimes a nice CYA. Unfortunately, tearing down the facade usually takes a lot of time and effort.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Keith McMillan</title>
		<link>http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/comment-page-1/#comment-4634</link>
		<dc:creator>Keith McMillan</dc:creator>
		<pubDate>Tue, 02 Mar 2010 15:15:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.adeptechllc.com/?p=273#comment-4634</guid>
		<description>Hello Rama,

&quot;Just enough&quot; is going to be different for every team, and for each activity you undertake, so it&#039;s not possible to give concrete guidance on how much is just enough.  

That&#039;s the reason I suggest that we ask &quot;why?&quot;  If we ask &quot;who needs this, and for what? Is this the best form for what they need?&quot; we stand a better chance of finding all that make-work we do &quot;just in case.&quot;  

We&#039;re always going to be asked to do more than is &quot;just enough&quot; but at least if we&#039;re asking the questions, we can try to keep our focus on providing just enough.

Thanks for your comments!
Keith</description>
		<content:encoded><![CDATA[<p>Hello Rama,</p>
<p>&#8220;Just enough&#8221; is going to be different for every team, and for each activity you undertake, so it&#8217;s not possible to give concrete guidance on how much is just enough.  </p>
<p>That&#8217;s the reason I suggest that we ask &#8220;why?&#8221;  If we ask &#8220;who needs this, and for what? Is this the best form for what they need?&#8221; we stand a better chance of finding all that make-work we do &#8220;just in case.&#8221;  </p>
<p>We&#8217;re always going to be asked to do more than is &#8220;just enough&#8221; but at least if we&#8217;re asking the questions, we can try to keep our focus on providing just enough.</p>
<p>Thanks for your comments!<br />
Keith</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rama</title>
		<link>http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/comment-page-1/#comment-4633</link>
		<dc:creator>Rama</dc:creator>
		<pubDate>Tue, 02 Mar 2010 11:45:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.adeptechllc.com/?p=273#comment-4633</guid>
		<description>Hi Keith
It is no doubt a very interesting and informative discussion. We face these kinds of issues often.
It will be really good if we extend this further and try to explore on how we could help the team define &quot; Just what is enough&quot;. I believe that many a times although the team members are aware of the &quot;Just enough&quot;, but what prevents them from implementing the thought is the litmus test for determining what is &quot; Just Enough&quot;.
Thoughts welcome
Regards
Rama</description>
		<content:encoded><![CDATA[<p>Hi Keith<br />
It is no doubt a very interesting and informative discussion. We face these kinds of issues often.<br />
It will be really good if we extend this further and try to explore on how we could help the team define &#8221; Just what is enough&#8221;. I believe that many a times although the team members are aware of the &#8220;Just enough&#8221;, but what prevents them from implementing the thought is the litmus test for determining what is &#8221; Just Enough&#8221;.<br />
Thoughts welcome<br />
Regards<br />
Rama</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Petri Heiramo</title>
		<link>http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/comment-page-1/#comment-4632</link>
		<dc:creator>Petri Heiramo</dc:creator>
		<pubDate>Mon, 01 Mar 2010 20:31:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.adeptechllc.com/?p=273#comment-4632</guid>
		<description>Nice post, and to the point. Thanks for writing it.


Yours, Petri</description>
		<content:encoded><![CDATA[<p>Nice post, and to the point. Thanks for writing it.</p>
<p>Yours, Petri</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Casey</title>
		<link>http://www.adeptechllc.com/2010/03/01/just-enough-vs-just-in-case/comment-page-1/#comment-4631</link>
		<dc:creator>Casey</dc:creator>
		<pubDate>Mon, 01 Mar 2010 15:46:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.adeptechllc.com/?p=273#comment-4631</guid>
		<description>Keith, a thousand times YES! I currently work for the large IT department you were recently consulting for, and this article really gets down to one of the major root causes of project delays here. I&#039;m tempted to print up t-shirts and posters with the phrase &quot;The antidote to &#039;just in case&#039; is &#039;just enough&#039;&quot; on them. Thanks for your insight.</description>
		<content:encoded><![CDATA[<p>Keith, a thousand times YES! I currently work for the large IT department you were recently consulting for, and this article really gets down to one of the major root causes of project delays here. I&#8217;m tempted to print up t-shirts and posters with the phrase &#8220;The antidote to &#8216;just in case&#8217; is &#8216;just enough&#8217;&#8221; on them. Thanks for your insight.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
