<?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 for Katherine Cook</title>
	<atom:link href="http://www.katherinecook.net/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.katherinecook.net</link>
	<description>Web Developer/College Student</description>
	<lastBuildDate>Tue, 24 Jan 2012 17:29:29 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1</generator>
	<item>
		<title>Comment on Effective Developer/Management Communication by Charles Mack</title>
		<link>http://www.katherinecook.net/2009/06/effective-developermanagement-communication/comment-page-1/#comment-4007</link>
		<dc:creator>Charles Mack</dc:creator>
		<pubDate>Tue, 24 Jan 2012 17:29:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.katherinecook.net/?p=6#comment-4007</guid>
		<description>Obviously communication is key.  If you have read the Mythical Man Month, I highly suggest it.   It is cornerstone for any software engineer, despite being written in the 70s.   There is constantly a juggling act between paying down technical debt for existing systems and creating new functionality.   Developers typically want to reinvent the entire wheel in an effort to pay down the technical debt.   Version 2 is always over-promised, under delivered, and often a failure.    Non-technical management only cares technical debt if it is slowing development of new functionality or if customers are complaining about non-functional requirements (speed, accuracy, etc).   

I think this can be balanced with test suites.  With large test suites in place, including but not limited to GUI functional, unit tests, or regression suites, one can move a light speed taking high risk of paying off that technical debt.   While it does feel like steering a ship while rebuilding its hull, at least the ship is reaches its destination.

I have always committed to being as open and communicative as possible and willing to take risks to meet a goal, either internal or external.    If development is not taking risks, developers, thus the company, are not innovating.  If a company is not innovating, management is failing.</description>
		<content:encoded><![CDATA[<p>Obviously communication is key.  If you have read the Mythical Man Month, I highly suggest it.   It is cornerstone for any software engineer, despite being written in the 70s.   There is constantly a juggling act between paying down technical debt for existing systems and creating new functionality.   Developers typically want to reinvent the entire wheel in an effort to pay down the technical debt.   Version 2 is always over-promised, under delivered, and often a failure.    Non-technical management only cares technical debt if it is slowing development of new functionality or if customers are complaining about non-functional requirements (speed, accuracy, etc).   </p>
<p>I think this can be balanced with test suites.  With large test suites in place, including but not limited to GUI functional, unit tests, or regression suites, one can move a light speed taking high risk of paying off that technical debt.   While it does feel like steering a ship while rebuilding its hull, at least the ship is reaches its destination.</p>
<p>I have always committed to being as open and communicative as possible and willing to take risks to meet a goal, either internal or external.    If development is not taking risks, developers, thus the company, are not innovating.  If a company is not innovating, management is failing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Summer by Richard</title>
		<link>http://www.katherinecook.net/2009/06/summer/comment-page-1/#comment-18</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Mon, 29 Jun 2009 19:57:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.katherinecook.net/?p=5#comment-18</guid>
		<description>More Blogging please!!!!! 

Imagine the old ovaltine commercials except for blogging!</description>
		<content:encoded><![CDATA[<p>More Blogging please!!!!! </p>
<p>Imagine the old ovaltine commercials except for blogging!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Effective Developer/Management Communication by Luke Barton</title>
		<link>http://www.katherinecook.net/2009/06/effective-developermanagement-communication/comment-page-1/#comment-13</link>
		<dc:creator>Luke Barton</dc:creator>
		<pubDate>Wed, 24 Jun 2009 08:39:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.katherinecook.net/?p=6#comment-13</guid>
		<description>Perfect. Absolutely spot on. I have seen this problem more than I&#039;d like to.

I&#039;d like to draw attention to the fact that I&#039;ve seen more developers able to identify these issues; including the causes, than managers.</description>
		<content:encoded><![CDATA[<p>Perfect. Absolutely spot on. I have seen this problem more than I&#8217;d like to.</p>
<p>I&#8217;d like to draw attention to the fact that I&#8217;ve seen more developers able to identify these issues; including the causes, than managers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Effective Developer/Management Communication by bagherra</title>
		<link>http://www.katherinecook.net/2009/06/effective-developermanagement-communication/comment-page-1/#comment-12</link>
		<dc:creator>bagherra</dc:creator>
		<pubDate>Mon, 22 Jun 2009 20:22:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.katherinecook.net/?p=6#comment-12</guid>
		<description>That was absolutely amazing.  Everything you have to say is spot on.  I think it is a tricky balancing act to determine what level of granularity is just right for communicating intent up, though.  If you give too little, you are accused of being lazy...you give too much and they feel inundated with information that is intended to confuse them (often termed &quot;gobbledy-gook&quot;).

Very poignant and well thought out.</description>
		<content:encoded><![CDATA[<p>That was absolutely amazing.  Everything you have to say is spot on.  I think it is a tricky balancing act to determine what level of granularity is just right for communicating intent up, though.  If you give too little, you are accused of being lazy&#8230;you give too much and they feel inundated with information that is intended to confuse them (often termed &#8220;gobbledy-gook&#8221;).</p>
<p>Very poignant and well thought out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Effective Developer/Management Communication by Promises and White Elephants :: Robert Stackhouse</title>
		<link>http://www.katherinecook.net/2009/06/effective-developermanagement-communication/comment-page-1/#comment-11</link>
		<dc:creator>Promises and White Elephants :: Robert Stackhouse</dc:creator>
		<pubDate>Mon, 22 Jun 2009 19:44:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.katherinecook.net/?p=6#comment-11</guid>
		<description>[...] student I know penned a very eloquent article on the failures of communication between development and management. The only thing I have to add [...]</description>
		<content:encoded><![CDATA[<p>[...] student I know penned a very eloquent article on the failures of communication between development and management. The only thing I have to add [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
