<?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: If somebody told you that their business plan was &#8220;first get big, then get profitable&#8221;</title>
	<atom:link href="http://leansoftwareengineering.com/2007/08/20/if-somebody-told-you-that-their-business-plan-was-first-get-big-then-get-profitable/feed/" rel="self" type="application/rss+xml" />
	<link>http://leansoftwareengineering.com/2007/08/20/if-somebody-told-you-that-their-business-plan-was-first-get-big-then-get-profitable/</link>
	<description>Essays on the Continuous Delivery of High Quality Information Systems</description>
	<lastBuildDate>Wed, 07 Jul 2010 10:00:18 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Corey</title>
		<link>http://leansoftwareengineering.com/2007/08/20/if-somebody-told-you-that-their-business-plan-was-first-get-big-then-get-profitable/comment-page-1/#comment-84</link>
		<dc:creator>Corey</dc:creator>
		<pubDate>Wed, 22 Aug 2007 23:16:53 +0000</pubDate>
		<guid isPermaLink="false">http://leansoftwareengineering.com/2007/08/20/if-somebody-told-you-that-their-business-plan-was-first-get-big-then-get-profitable/#comment-84</guid>
		<description>Yes, it is certainly prudent to be worried about such an assertion.  I know I would be.

The problem of conceptual integrity can be mitigated by requiring satisfaction of robustness criteria for every increment.  This can be machine assisted by application of the Independence and Information Axioms, and Design of Experiment.  A system with poor conceptual integrity will always fail the test of the Independence Axiom.

The problem of communication is mitigated by limiting the scope of any individual change to the system and requiring that integration is completed to a high level of reliability. The question becomes:  can you add an increment to an arbitrarily large system and preserve or enhance its reliability in the process?  If the answer is yes, then repeat indefinitely.

The scalability of a lean system &lt;em&gt;will&lt;/em&gt; be limited by something, just not the factors behind Brooks&#039; Law.  

&lt;em&gt;For the scholarly or the highly motivated, the rationale behind my assertion is due to the reduction of combinatorial complexity to periodic complexity.  Here is a lovely paper on the subject: http://web.mit.edu/pccs/pub/2003/tlee-complexity.html&lt;/em&gt;
</description>
		<content:encoded><![CDATA[<p>Yes, it is certainly prudent to be worried about such an assertion.  I know I would be.</p>
<p>The problem of conceptual integrity can be mitigated by requiring satisfaction of robustness criteria for every increment.  This can be machine assisted by application of the Independence and Information Axioms, and Design of Experiment.  A system with poor conceptual integrity will always fail the test of the Independence Axiom.</p>
<p>The problem of communication is mitigated by limiting the scope of any individual change to the system and requiring that integration is completed to a high level of reliability. The question becomes:  can you add an increment to an arbitrarily large system and preserve or enhance its reliability in the process?  If the answer is yes, then repeat indefinitely.</p>
<p>The scalability of a lean system <em>will</em> be limited by something, just not the factors behind Brooks&#8217; Law.  </p>
<p><em>For the scholarly or the highly motivated, the rationale behind my assertion is due to the reduction of combinatorial complexity to periodic complexity.  Here is a lovely paper on the subject: <a href="http://web.mit.edu/pccs/pub/2003/tlee-complexity.html" rel="nofollow">http://web.mit.edu/pccs/pub/20.....exity.html</a></em></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin Cron</title>
		<link>http://leansoftwareengineering.com/2007/08/20/if-somebody-told-you-that-their-business-plan-was-first-get-big-then-get-profitable/comment-page-1/#comment-83</link>
		<dc:creator>Martin Cron</dc:creator>
		<pubDate>Wed, 22 Aug 2007 22:32:19 +0000</pubDate>
		<guid isPermaLink="false">http://leansoftwareengineering.com/2007/08/20/if-somebody-told-you-that-their-business-plan-was-first-get-big-then-get-profitable/#comment-83</guid>
		<description>This is a great post outlining a good concept, but I&#039;m a little worried by any assertion that Brooks&#039; law only applies to the product/project approach to software development and is somehow obsolete with better practices.

The diminishing returns around Brooks&#039; law come from communication overhead and problems aligning conceptual integrity. Those problems don&#039;t completely go away with an incremental approach.</description>
		<content:encoded><![CDATA[<p>This is a great post outlining a good concept, but I&#8217;m a little worried by any assertion that Brooks&#8217; law only applies to the product/project approach to software development and is somehow obsolete with better practices.</p>
<p>The diminishing returns around Brooks&#8217; law come from communication overhead and problems aligning conceptual integrity. Those problems don&#8217;t completely go away with an incremental approach.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.399 seconds -->
