<?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: The Quest For Perfect Proportions In Your Software</title>
	<atom:link href="http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/</link>
	<description>Ideas for building efficient developers and software</description>
	<lastBuildDate>Tue, 16 Mar 2010 08:56:32 +0000</lastBuildDate>
	
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Jeff Rhines</title>
		<link>http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-2621</link>
		<dc:creator>Jeff Rhines</dc:creator>
		<pubDate>Tue, 05 Aug 2008 14:48:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-2621</guid>
		<description>I was thinking about something similar this past weekend.  Instead of terms of software size, I was considering schedule, which is closely correlated.  We need an online repository that folks can submit the size of their projects&#039; layers along with some other details about the project.  Objective details could include language break-out within the layers (Java, C, SQL, Ruby), application type, even size of the team, number of persons in each layer or phase of the project (architects, managers, ui designers, coders), etc.  Subjective details would be just as interesting.  How enjoyable was this project to work on?  Do you feel it is larger or smaller than it should be and by how much?</description>
		<content:encoded><![CDATA[<p>I was thinking about something similar this past weekend.  Instead of terms of software size, I was considering schedule, which is closely correlated.  We need an online repository that folks can submit the size of their projects&#8217; layers along with some other details about the project.  Objective details could include language break-out within the layers (Java, C, SQL, Ruby), application type, even size of the team, number of persons in each layer or phase of the project (architects, managers, ui designers, coders), etc.  Subjective details would be just as interesting.  How enjoyable was this project to work on?  Do you feel it is larger or smaller than it should be and by how much?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: &#187; Daily Bits - February 5, 2008 Alvin Ashcraft&#8217;s Daily Geek Bits: Daily links, development, gadgets and raising rugrats.</title>
		<link>http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1033</link>
		<dc:creator>&#187; Daily Bits - February 5, 2008 Alvin Ashcraft&#8217;s Daily Geek Bits: Daily links, development, gadgets and raising rugrats.</dc:creator>
		<pubDate>Tue, 05 Feb 2008 13:23:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1033</guid>
		<description>[...] The Quest For Perfect Proportions in Your Software (Max Pool) [...]</description>
		<content:encoded><![CDATA[<p>[...] The Quest For Perfect Proportions in Your Software (Max Pool) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Max Pool</title>
		<link>http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1031</link>
		<dc:creator>Max Pool</dc:creator>
		<pubDate>Mon, 04 Feb 2008 18:17:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1031</guid>
		<description>@Scott -

Can we be for sure? 

I know for a fact that you estimate with the Fibonacci numbers, which in turn can be represented by the Golden Spiral.  

So in short, your estimation technique actually has an underlying mathematical pattern.

True, I do agree that our focus should be more turned to building solution in an agile fashion, but wouldn&#039;t it be cool if we stumbled across the perfect ratio from which we could then gauge code bloat in frameworks and solutions?</description>
		<content:encoded><![CDATA[<p>@Scott -</p>
<p>Can we be for sure? </p>
<p>I know for a fact that you estimate with the Fibonacci numbers, which in turn can be represented by the Golden Spiral.  </p>
<p>So in short, your estimation technique actually has an underlying mathematical pattern.</p>
<p>True, I do agree that our focus should be more turned to building solution in an agile fashion, but wouldn&#8217;t it be cool if we stumbled across the perfect ratio from which we could then gauge code bloat in frameworks and solutions?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Bellware</title>
		<link>http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1030</link>
		<dc:creator>Scott Bellware</dc:creator>
		<pubDate>Mon, 04 Feb 2008 17:52:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1030</guid>
		<description>There&#039;s no universally-appropriate proportion to the size of architectural layers.

The size of the layers (let alone the relative size, which is merely a side effect) is a reflection of the needs and requirements of a system, including the user experience demands, the complexity of the domain that it serves, and the distribution of the resources that the application addresses, among other concerns.

Consider that the golden ration is often used to address and represent constraints in the physical world.  Software isn&#039;t directly accountable to the laws of physics that are in play when constructing the material world.</description>
		<content:encoded><![CDATA[<p>There&#8217;s no universally-appropriate proportion to the size of architectural layers.</p>
<p>The size of the layers (let alone the relative size, which is merely a side effect) is a reflection of the needs and requirements of a system, including the user experience demands, the complexity of the domain that it serves, and the distribution of the resources that the application addresses, among other concerns.</p>
<p>Consider that the golden ration is often used to address and represent constraints in the physical world.  Software isn&#8217;t directly accountable to the laws of physics that are in play when constructing the material world.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jake Good</title>
		<link>http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1028</link>
		<dc:creator>Jake Good</dc:creator>
		<pubDate>Mon, 04 Feb 2008 16:08:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1028</guid>
		<description>I think that it has a lot to do with it right? The more powerful API you are handed (whether it&#039;s View, Controller, or Model)... the less code that the layer using the API has to write...

It might be the case that due to platform / frameworks, the MVC &quot;weight&quot; is like the classic push pull graph that describes time vs complexity vs flexibility...

If you tug on the UI to do most of the work, you have to route your controllers and models to fit their abstractions... if you have a thick model, you have to morph your controller to fit the UI and the Model abstractions...

What if you&#039;re controller is the thick spot and has a lot of abstractions, does your controller have to grow to fit in the with model and view? It seems so... which leads me to believe that your golden ratio might be the key... 

Good thoughts to have on a Monday morning!</description>
		<content:encoded><![CDATA[<p>I think that it has a lot to do with it right? The more powerful API you are handed (whether it&#8217;s View, Controller, or Model)&#8230; the less code that the layer using the API has to write&#8230;</p>
<p>It might be the case that due to platform / frameworks, the MVC &#8220;weight&#8221; is like the classic push pull graph that describes time vs complexity vs flexibility&#8230;</p>
<p>If you tug on the UI to do most of the work, you have to route your controllers and models to fit their abstractions&#8230; if you have a thick model, you have to morph your controller to fit the UI and the Model abstractions&#8230;</p>
<p>What if you&#8217;re controller is the thick spot and has a lot of abstractions, does your controller have to grow to fit in the with model and view? It seems so&#8230; which leads me to believe that your golden ratio might be the key&#8230; </p>
<p>Good thoughts to have on a Monday morning!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Max Pool</title>
		<link>http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1027</link>
		<dc:creator>Max Pool</dc:creator>
		<pubDate>Mon, 04 Feb 2008 14:21:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1027</guid>
		<description>@Jake - 

When I wrote this I was thinking more along the lines that I hoped most applications had a thicker business logic controller layer and kept both the UI and Domain layers fairly anemic.

Your point does resonate with me as I find ASP.NET, JSP, Swing, and WinForms very bloated UI layers.  ASP.NET MVC, Spring, and Ruby all do a much better job of bringing this bloat back into proportions.

So thats interesting, sometimes are we forced to deviate away from a &quot;golden ratio&quot; solely based on the framework we are using?</description>
		<content:encoded><![CDATA[<p>@Jake &#8211; </p>
<p>When I wrote this I was thinking more along the lines that I hoped most applications had a thicker business logic controller layer and kept both the UI and Domain layers fairly anemic.</p>
<p>Your point does resonate with me as I find ASP.NET, JSP, Swing, and WinForms very bloated UI layers.  ASP.NET MVC, Spring, and Ruby all do a much better job of bringing this bloat back into proportions.</p>
<p>So thats interesting, sometimes are we forced to deviate away from a &#8220;golden ratio&#8221; solely based on the framework we are using?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jake Good</title>
		<link>http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1026</link>
		<dc:creator>Jake Good</dc:creator>
		<pubDate>Mon, 04 Feb 2008 14:13:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/the-quest-for-perfect-proportions-in-your-software/#comment-1026</guid>
		<description>I would say that your ratio is only that way (Control Layer being 1.6x) because it has to be to support the crazy UI layers that are available to us... 

For instance, Windows Forms and ASP.Net... lots of code to get simple UIs up and running with a controller.

But it doesn&#039;t have to be that way...

In the Rails world, they like to take the Model being 1.6x, making things more readable in the UI and the model layer being the brute force of the attack through abstraction. They get away with that due to the Controller and View layer using BCLs. Arrays, ints, strings, etc. No fancy object models like ComboBoxItem.

Just some thoughts...</description>
		<content:encoded><![CDATA[<p>I would say that your ratio is only that way (Control Layer being 1.6x) because it has to be to support the crazy UI layers that are available to us&#8230; </p>
<p>For instance, Windows Forms and ASP.Net&#8230; lots of code to get simple UIs up and running with a controller.</p>
<p>But it doesn&#8217;t have to be that way&#8230;</p>
<p>In the Rails world, they like to take the Model being 1.6x, making things more readable in the UI and the model layer being the brute force of the attack through abstraction. They get away with that due to the Controller and View layer using BCLs. Arrays, ints, strings, etc. No fancy object models like ComboBoxItem.</p>
<p>Just some thoughts&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
