<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Silos and Architecture Astronauts</title>
	<link>http://dubroy.com/blog/2007/01/22/silos-and-architecture-astronauts/</link>
	<description>on programming, usability, and design; by Patrick Dubroy</description>
	<pubDate>Mon, 08 Sep 2008 06:51:28 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Patrick</title>
		<link>http://dubroy.com/blog/2007/01/22/silos-and-architecture-astronauts/#comment-66</link>
		<pubDate>Wed, 07 Feb 2007 19:03:36 +0000</pubDate>
		<guid>http://dubroy.com/blog/2007/01/22/silos-and-architecture-astronauts/#comment-66</guid>
					<description>&lt;p&gt;It's true, the Chandler people never really made it clear what their solution was, in concrete form. The were lots of sweeping "vision" statements, but no real answer of "what's it going to do for me?" But I still think they correctly identified the problem, even if they haven't come up with a solution.&lt;/p&gt;

&lt;p&gt;Well, I'm not sure I agree that emphasis on code quality is misplaced. When you're developing software, you want a quality product with minimal development time. Code quality may be only weakly correlated to product quality, but I think it's strongly related to development time. In a messy code base, changes (improvements as well as bug fixes) take longer to make, and carry a greater risk of introducing breakage.&lt;/p&gt;

&lt;p&gt;But, I do think it's important to clarify what "code quality" means. On my old team at IBM, we used to have a rule: it's okay to be bogus, just be consistently bogus. I think that quality code is code that is consistent, simple, and easy to understand. The problem is that for many people, "quality code" means that code that is ridiculously general purpose, refactored to the nth degree for no reason.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>It&#8217;s true, the Chandler people never really made it clear what their solution was, in concrete form. The were lots of sweeping &#8220;vision&#8221; statements, but no real answer of &#8220;what&#8217;s it going to do for me?&#8221; But I still think they correctly identified the problem, even if they haven&#8217;t come up with a solution.</p>
<p>Well, I&#8217;m not sure I agree that emphasis on code quality is misplaced. When you&#8217;re developing software, you want a quality product with minimal development time. Code quality may be only weakly correlated to product quality, but I think it&#8217;s strongly related to development time. In a messy code base, changes (improvements as well as bug fixes) take longer to make, and carry a greater risk of introducing breakage.</p>
<p>But, I do think it&#8217;s important to clarify what &#8220;code quality&#8221; means. On my old team at IBM, we used to have a rule: it&#8217;s okay to be bogus, just be consistently bogus. I think that quality code is code that is consistent, simple, and easy to understand. The problem is that for many people, &#8220;quality code&#8221; means that code that is ridiculously general purpose, refactored to the nth degree for no reason.</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Colin Stewart</title>
		<link>http://dubroy.com/blog/2007/01/22/silos-and-architecture-astronauts/#comment-63</link>
		<pubDate>Wed, 07 Feb 2007 03:21:07 +0000</pubDate>
		<guid>http://dubroy.com/blog/2007/01/22/silos-and-architecture-astronauts/#comment-63</guid>
					<description>&lt;p&gt;I'm certainly not one to vilify chasing big ideas, but you do have to be able to connect the vision to some idea of reality.  Just saying "no silos" isn't enough; there needs to be an alternative.  Something concrete enough that you can counter all of the silly misinterpretations people are going to come up with.  I looked through the Chandler philosophy documents and I can't say I "get it".&lt;/p&gt;

&lt;p&gt;I do agree that the analogy to architectural astronauts is a little off the mark.  The real problem with architectural astronauts is not the idealism so much as is the misplaced emphasis on code quality, rather than product quality.  I would say the two kinds of quality are only weakly correlated.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I&#8217;m certainly not one to vilify chasing big ideas, but you do have to be able to connect the vision to some idea of reality.  Just saying &#8220;no silos&#8221; isn&#8217;t enough; there needs to be an alternative.  Something concrete enough that you can counter all of the silly misinterpretations people are going to come up with.  I looked through the Chandler philosophy documents and I can&#8217;t say I &#8220;get it&#8221;.</p>
<p>I do agree that the analogy to architectural astronauts is a little off the mark.  The real problem with architectural astronauts is not the idealism so much as is the misplaced emphasis on code quality, rather than product quality.  I would say the two kinds of quality are only weakly correlated.</p>
]]></content:encoded>
				</item>
</channel>
</rss>
