<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" 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/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" version="2.0">

<channel>
	<title>Reflections on Software Engineering</title>
	
	<link>http://neverletdown.net</link>
	<description>by Michael Keeling</description>
	<lastBuildDate>Wed, 14 Sep 2011 02:23:54 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://feeds.feedburner.com/neverletdown" /><feedburner:info uri="neverletdown" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><feedburner:emailServiceId>neverletdown</feedburner:emailServiceId><feedburner:feedburnerHostname>http://feedburner.google.com</feedburner:feedburnerHostname><item>
		<title>Guidelines for the System Metaphor</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/79hwcZYcvmk/</link>
		<comments>http://neverletdown.net/2011/08/guidelines-for-the-system-metaphor/#comments</comments>
		<pubDate>Mon, 29 Aug 2011 15:00:36 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Architecture]]></category>
		<category><![CDATA[Talks]]></category>
		<category><![CDATA[Agile2011]]></category>
		<category><![CDATA[conference]]></category>
		<category><![CDATA[extreme programming]]></category>
		<category><![CDATA[Kent Beck]]></category>
		<category><![CDATA[software architecture]]></category>
		<category><![CDATA[software design]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[System Metaphor]]></category>
		<category><![CDATA[XP]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=478</guid>
		<description><![CDATA[Extreme Programming’s system metaphor, as traditionally presented, has a fatal flaw. It has a nudge which encourages teams to describe the system at too high a level, as one large monolithic thing. The result is nearly always the same: a generic metaphor that doesn’t really describe the software and provides next to no guidance for [...]]]></description>
			<content:encoded><![CDATA[Extreme Programming’s system metaphor, as traditionally presented, has a fatal flaw. It has a nudge which encourages teams to describe the system at too high a level, as one large monolithic thing. The result is nearly always the same: a generic me<img src="http://feeds.feedburner.com/~r/neverletdown/~4/79hwcZYcvmk" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2011/08/guidelines-for-the-system-metaphor/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2011/08/guidelines-for-the-system-metaphor/</feedburner:origLink></item>
		<item>
		<title>See you at Agile2011 in Salt Lake City!</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/KlRV-R_YsRg/</link>
		<comments>http://neverletdown.net/2011/07/see-you-at-agile2011-in-salt-lake-city/#comments</comments>
		<pubDate>Wed, 27 Jul 2011 14:00:32 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Architecture]]></category>
		<category><![CDATA[Agile2011]]></category>
		<category><![CDATA[conference]]></category>
		<category><![CDATA[extreme programming]]></category>
		<category><![CDATA[software architecture]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[System Metaphor]]></category>
		<category><![CDATA[XP]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=453</guid>
		<description><![CDATA[Here’s an introduction to my Agile2011 talk. Come hang out with me for 30 minutes on Tuesday, August 9 at 2:00pm in the LA Teton and bring your thoughts and questions about agile, architecture, and the system metaphor. And please show your intere]]></description>
			<content:encoded><![CDATA[Here’s an introduction to my Agile2011 talk.  Come hang out with me for 30 minutes on Tuesday, August 9 at 2:00pm in the LA Teton and bring your thoughts and questions about agile, architecture, and the system metaphor.  And please show your intere<img src="http://feeds.feedburner.com/~r/neverletdown/~4/KlRV-R_YsRg" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2011/07/see-you-at-agile2011-in-salt-lake-city/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2011/07/see-you-at-agile2011-in-salt-lake-city/</feedburner:origLink></item>
		<item>
		<title>Change Your Team’s Oil</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/IeHnrJCy6BA/</link>
		<comments>http://neverletdown.net/2011/06/change-your-teams-oil/#comments</comments>
		<pubDate>Thu, 16 Jun 2011 02:45:30 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Process]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[process improvement]]></category>
		<category><![CDATA[reflection]]></category>
		<category><![CDATA[retrospectives]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=437</guid>
		<description><![CDATA[Every 5,000 miles or so I take my car in to the shop for an oil change. It's part of the routine, preventative maintenance I do to keep my car running in tip top shape. Routine maintenance gives me the peace of mind that my car won't leave me stran]]></description>
			<content:encoded><![CDATA[Every 5,000 miles or so I take my car in to the shop for an oil change.  It's part of the routine, preventative maintenance I do to keep my car running in tip top shape.  Routine maintenance gives me the peace of mind that my car won't leave me stran<img src="http://feeds.feedburner.com/~r/neverletdown/~4/IeHnrJCy6BA" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2011/06/change-your-teams-oil/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2011/06/change-your-teams-oil/</feedburner:origLink></item>
		<item>
		<title>Why I Pledge an Oath on Non-Allegiance</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/fE2FMbTo3JA/</link>
		<comments>http://neverletdown.net/2011/04/why-i-pledge-an-oath-on-non-allegiance/#comments</comments>
		<pubDate>Sat, 16 Apr 2011 03:12:23 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Process]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[relationship]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=424</guid>
		<description><![CDATA[When building relationships we look for commonalities between ourselves and others. When we have things in common it makes us feel good, like we're not alone in the world. And the things we have in common become the basis for lasting relationships.]]></description>
			<content:encoded><![CDATA[When building relationships we look for commonalities between ourselves and others.  When we have things in common it makes us feel good, like we're not alone in the world.  And the things we have in common become the basis for lasting relationships.<img src="http://feeds.feedburner.com/~r/neverletdown/~4/fE2FMbTo3JA" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2011/04/why-i-pledge-an-oath-on-non-allegiance/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2011/04/why-i-pledge-an-oath-on-non-allegiance/</feedburner:origLink></item>
		<item>
		<title>Exploring the Design Space</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/geOArKe-am4/</link>
		<comments>http://neverletdown.net/2010/09/exploring-the-design-space/#comments</comments>
		<pubDate>Fri, 03 Sep 2010 14:18:01 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Architecture]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[bduf]]></category>
		<category><![CDATA[Big Design Up Front]]></category>
		<category><![CDATA[emergent design]]></category>
		<category><![CDATA[science of the artificial]]></category>
		<category><![CDATA[software architecture]]></category>
		<category><![CDATA[software design]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=405</guid>
		<description><![CDATA[In Choosing a Software Design Strategy I proposed that your understanding of the design space will determine what design strategies are appropriate for your project. That is, how much you know about the problem domain and solution space will determi]]></description>
			<content:encoded><![CDATA[In Choosing a Software Design Strategy I proposed that your understanding of the design space will determine what design strategies are appropriate for your project.  That is, how much you know about the problem domain and solution space will determi<img src="http://feeds.feedburner.com/~r/neverletdown/~4/geOArKe-am4" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/09/exploring-the-design-space/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/09/exploring-the-design-space/</feedburner:origLink></item>
		<item>
		<title>Choosing a Software Design Strategy</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/aApRWwT2fWU/</link>
		<comments>http://neverletdown.net/2010/08/choosing-a-software-design-strategy/#comments</comments>
		<pubDate>Mon, 02 Aug 2010 22:01:36 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Architecture]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Risk Management]]></category>
		<category><![CDATA[ACDM]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[emergent design]]></category>
		<category><![CDATA[science of the artificial]]></category>
		<category><![CDATA[software design]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=384</guid>
		<description><![CDATA[I was reading an article from the Joel on Software archives and was struck by this quote from The Project Aardvark Spec: I can't tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I]]></description>
			<content:encoded><![CDATA[I was reading an article from the Joel on Software archives and was struck by this quote from The Project Aardvark Spec:
I can't tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I<img src="http://feeds.feedburner.com/~r/neverletdown/~4/aApRWwT2fWU" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/08/choosing-a-software-design-strategy/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/08/choosing-a-software-design-strategy/</feedburner:origLink></item>
		<item>
		<title>Improvisational Architecture</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/nl-S8iV5uu0/</link>
		<comments>http://neverletdown.net/2010/07/improvisational-architecture/#comments</comments>
		<pubDate>Fri, 16 Jul 2010 04:30:14 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Architecture]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[Big Design Up Front]]></category>
		<category><![CDATA[emergent design]]></category>
		<category><![CDATA[improvisation]]></category>
		<category><![CDATA[jazz]]></category>
		<category><![CDATA[software design]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[xp2010]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=370</guid>
		<description><![CDATA[If you were to go to two improvisational jazz performances, even two concerts by the same band, you'd hear different music at each show. The thrill of experiencing something unique, as it is created, without any kind of real plan or rehearsal, is bo]]></description>
			<content:encoded><![CDATA[If you were to go to two improvisational jazz performances, even two concerts by the same band, you'd hear different music at each show.  The thrill of experiencing something unique, as it is created, without any kind of real plan or rehearsal, is bo<img src="http://feeds.feedburner.com/~r/neverletdown/~4/nl-S8iV5uu0" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/07/improvisational-architecture/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/07/improvisational-architecture/</feedburner:origLink></item>
		<item>
		<title>Hacking is not a Dirty Word</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/uSMjiYTTqQ0/</link>
		<comments>http://neverletdown.net/2010/07/hacking-is-not-a-dirty-word/#comments</comments>
		<pubDate>Fri, 02 Jul 2010 03:21:42 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[Process]]></category>
		<category><![CDATA[action research]]></category>
		<category><![CDATA[hacking]]></category>
		<category><![CDATA[myth busting]]></category>
		<category><![CDATA[process improvement]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[technical debt]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=358</guid>
		<description><![CDATA[I used to think hacking was bad. It was something you did when you didn’t have a plan, when you didn’t know what you were doing; it’s what amateurs do, noodling around the code without clear direction or intent. Or it was something you did, q]]></description>
			<content:encoded><![CDATA[I used to think hacking was bad.  It was something you did when you didn’t have a plan, when you didn’t know what you were doing; it’s what amateurs do, noodling around the code without clear direction or intent.  Or it was something you did, q<img src="http://feeds.feedburner.com/~r/neverletdown/~4/uSMjiYTTqQ0" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/07/hacking-is-not-a-dirty-word/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/07/hacking-is-not-a-dirty-word/</feedburner:origLink></item>
		<item>
		<title>Lightweight Experiments for Process Improvement</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/qbMMe_FUnBI/</link>
		<comments>http://neverletdown.net/2010/06/lightweight-experiments-for-process-improvement/#comments</comments>
		<pubDate>Tue, 15 Jun 2010 13:30:43 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[Talks]]></category>
		<category><![CDATA[experiment]]></category>
		<category><![CDATA[experimentation]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[measurement]]></category>
		<category><![CDATA[measures]]></category>
		<category><![CDATA[Metrics]]></category>
		<category><![CDATA[MSE]]></category>
		<category><![CDATA[pair programming]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[process improvement]]></category>
		<category><![CDATA[Risk Management]]></category>
		<category><![CDATA[science]]></category>
		<category><![CDATA[scientific method]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[studio]]></category>
		<category><![CDATA[XP]]></category>
		<category><![CDATA[xp2010]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=339</guid>
		<description><![CDATA[[This post is a recap on the second talk I gave at XP2010. This was the big one, the experience report talk, one of 15 experience reports published at XP2010. You can download the slides (pdf) or the full paper (pdf) from this website or from XP2010.]]></description>
			<content:encoded><![CDATA[[This post is a recap on the second talk I gave at XP2010. This was the big one, the experience report talk, one of 15 experience reports published at XP2010. You can download the slides (pdf) or the full paper (pdf) from this website or from XP2010.<img src="http://feeds.feedburner.com/~r/neverletdown/~4/qbMMe_FUnBI" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/06/lightweight-experiments-for-process-improvement/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/06/lightweight-experiments-for-process-improvement/</feedburner:origLink></item>
		<item>
		<title>Lessons from a Software Engineering Dojo</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/ZoUqvfqhHsk/</link>
		<comments>http://neverletdown.net/2010/06/lessons-from-a-software-engineering-dojo/#comments</comments>
		<pubDate>Thu, 10 Jun 2010 14:00:17 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Leadership]]></category>
		<category><![CDATA[Talks]]></category>
		<category><![CDATA[Carnegie Mellon]]></category>
		<category><![CDATA[coaching]]></category>
		<category><![CDATA[conference]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[mentoring]]></category>
		<category><![CDATA[MSE]]></category>
		<category><![CDATA[presentation]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[xp2010]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=323</guid>
		<description><![CDATA[[Here's a recap of the first talk I gave at XP2010. Since it was a Lightning Talk, rather than posting slides I've summarized my talk and added references directly in this post. I welcome comments and discussion.] Craftsmanship is an interesting]]></description>
			<content:encoded><![CDATA[[Here's a recap of the first talk I gave at XP2010.  Since it was a Lightning Talk, rather than posting slides I've summarized my talk and added references directly in this post.  I welcome comments and discussion.]

Craftsmanship is an interesting<img src="http://feeds.feedburner.com/~r/neverletdown/~4/ZoUqvfqhHsk" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/06/lessons-from-a-software-engineering-dojo/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/06/lessons-from-a-software-engineering-dojo/</feedburner:origLink></item>
		<item>
		<title>See you at XP2010 in Trondheim, Norway!</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/jlBmeBITyGc/</link>
		<comments>http://neverletdown.net/2010/06/see-you-at-xp2010-in-trondheim-norway/#comments</comments>
		<pubDate>Tue, 01 Jun 2010 17:30:57 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[experiment]]></category>
		<category><![CDATA[extreme programming]]></category>
		<category><![CDATA[pair programming]]></category>
		<category><![CDATA[process improvement]]></category>
		<category><![CDATA[science]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[XP]]></category>
		<category><![CDATA[xp2010]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=309</guid>
		<description><![CDATA[As I’m writing this I am making final preparations to leave for Trondheim, Norway to present an experience report at the 11th International Conference on Agile Software Development and Extreme Programming, or XP2010. After my experience report was]]></description>
			<content:encoded><![CDATA[As I’m writing this I am making final preparations to leave for Trondheim, Norway to present an experience report at the 11th International Conference on Agile Software Development and Extreme Programming, or XP2010.  After my experience report was<img src="http://feeds.feedburner.com/~r/neverletdown/~4/jlBmeBITyGc" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/06/see-you-at-xp2010-in-trondheim-norway/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/06/see-you-at-xp2010-in-trondheim-norway/</feedburner:origLink></item>
		<item>
		<title>The Reality of Risk Exposure</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/Tjg8aHEcyO8/</link>
		<comments>http://neverletdown.net/2010/05/the-reality-of-risk-exposure/#comments</comments>
		<pubDate>Sun, 16 May 2010 02:31:24 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Risk Management]]></category>
		<category><![CDATA[analysis]]></category>
		<category><![CDATA[impact]]></category>
		<category><![CDATA[Metrics]]></category>
		<category><![CDATA[probability]]></category>
		<category><![CDATA[Small team Risk Evaluation workshop]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[SRE]]></category>
		<category><![CDATA[studio]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=295</guid>
		<description><![CDATA[Over the past few weeks I’ve been thinking a lot about risk exposure in the context of managing projects. Exposure is a technique used almost universally when managing risks, yet as I’ve already discussed, exposure can cause major problems becau]]></description>
			<content:encoded><![CDATA[Over the past few weeks I’ve been thinking a lot about risk exposure in the context of managing projects.  Exposure is a technique used almost universally when managing risks, yet as I’ve already discussed, exposure can cause major problems becau<img src="http://feeds.feedburner.com/~r/neverletdown/~4/Tjg8aHEcyO8" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/05/the-reality-of-risk-exposure/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/05/the-reality-of-risk-exposure/</feedburner:origLink></item>
		<item>
		<title>A Closer Look at Risk Burndown</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/KuU0JuUfyrc/</link>
		<comments>http://neverletdown.net/2010/05/a-closer-look-at-risk-burndown/#comments</comments>
		<pubDate>Sun, 02 May 2010 02:17:34 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Metrics]]></category>
		<category><![CDATA[Risk Management]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[burndown]]></category>
		<category><![CDATA[measurement]]></category>
		<category><![CDATA[measures]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[tracking]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=265</guid>
		<description><![CDATA[I like the idea of the risk burndown chart. Burndown is an effective and satisfying visual indicator of progress and it’s relatively easy to calculate to boot. But does looking at a project’s risks through the lens of a burndown chart make sens]]></description>
			<content:encoded><![CDATA[I like the idea of the risk burndown chart.  Burndown is an effective and satisfying visual indicator of progress and it’s relatively easy to calculate to boot.  But does looking at a project’s risks through the lens of a burndown chart make sens<img src="http://feeds.feedburner.com/~r/neverletdown/~4/KuU0JuUfyrc" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/05/a-closer-look-at-risk-burndown/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/05/a-closer-look-at-risk-burndown/</feedburner:origLink></item>
		<item>
		<title>Is Better the Enemy of Good Enough?</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/Scpzx1JJH5o/</link>
		<comments>http://neverletdown.net/2010/04/is-better-the-enemy-of-good-enough/#comments</comments>
		<pubDate>Thu, 15 Apr 2010 14:19:45 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[process improvement]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=254</guid>
		<description><![CDATA["Better is the enemy of good enough" is a phrase often held up as the reason for not making changes on a team. If everything seems "good enough," the effort to make something better is regarded as waste. A lot of times, "good enough" is defied in te]]></description>
			<content:encoded><![CDATA["Better is the enemy of good enough" is a phrase often held up as the reason for not making changes on a team. If everything seems "good enough," the effort to make something better is regarded as waste.  A lot of times, "good enough" is defied in te<img src="http://feeds.feedburner.com/~r/neverletdown/~4/Scpzx1JJH5o" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/04/is-better-the-enemy-of-good-enough/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/04/is-better-the-enemy-of-good-enough/</feedburner:origLink></item>
		<item>
		<title>Book Review: The Design of Design by Fred Brooks</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/UnirsyxAf9g/</link>
		<comments>http://neverletdown.net/2010/04/book-review-the-design-of-design-by-fred-brooks/#comments</comments>
		<pubDate>Thu, 01 Apr 2010 14:15:31 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Book Review]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Fred Brooks]]></category>
		<category><![CDATA[science of the artificial]]></category>
		<category><![CDATA[software design]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[waterfall]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=242</guid>
		<description><![CDATA[During one of the last discussions in my great papers in software engineering reading course Mary Shaw, our discussion moderator, casually alluded to a follow-up class in the next fall semester, "Fred sent me an early draft manuscript of a book he’]]></description>
			<content:encoded><![CDATA[During one of the last discussions in my great papers in software engineering reading course Mary Shaw, our discussion moderator, casually alluded to a follow-up class in the next fall semester, "Fred sent me an early draft manuscript of a book he’<img src="http://feeds.feedburner.com/~r/neverletdown/~4/UnirsyxAf9g" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/04/book-review-the-design-of-design-by-fred-brooks/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/04/book-review-the-design-of-design-by-fred-brooks/</feedburner:origLink></item>
		<item>
		<title>Carpool Musings on Women in Science and Engineering</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/ON0QlsAHU3U/</link>
		<comments>http://neverletdown.net/2010/03/carpool-musings-on-women-in-science-and-engineering/#comments</comments>
		<pubDate>Thu, 25 Mar 2010 02:19:49 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Engineering]]></category>
		<category><![CDATA[Ada Lovelace Day]]></category>
		<category><![CDATA[change]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=231</guid>
		<description><![CDATA[Over the past few weeks there has been a rash of studies published discussing why there are so few women in the science and technology fields. On a high note, one of these studies noticed that recently about the same number of women are graduating w]]></description>
			<content:encoded><![CDATA[Over the past few weeks there has been a rash of studies published discussing why there are so few women in the science and technology fields.  On a high note, one of these studies noticed that recently about the same number of women are graduating w<img src="http://feeds.feedburner.com/~r/neverletdown/~4/ON0QlsAHU3U" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/03/carpool-musings-on-women-in-science-and-engineering/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/03/carpool-musings-on-women-in-science-and-engineering/</feedburner:origLink></item>
		<item>
		<title>Identifying Process Affordances: Nudging Toward Change</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/MUyn_Yofgv0/</link>
		<comments>http://neverletdown.net/2010/03/identifying-process-affordances-nudging-toward-change/#comments</comments>
		<pubDate>Tue, 16 Mar 2010 03:16:26 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[Talks]]></category>
		<category><![CDATA[affordance]]></category>
		<category><![CDATA[conference]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[Donald Norman]]></category>
		<category><![CDATA[nudge]]></category>
		<category><![CDATA[process improvement]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[studio]]></category>
		<category><![CDATA[talk]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=184</guid>
		<description><![CDATA[This post is a recap of a talk I gave this weekend at the Carnegie Mellon University Master of Software Engineering 20th Anniversary Mini-Conference. I’ve made the paper this talk is based on (pdf) as well as the slides I used during the talk (pdf]]></description>
			<content:encoded><![CDATA[This post is a recap of a talk I gave this weekend at the Carnegie Mellon University Master of Software Engineering 20th Anniversary Mini-Conference.  I’ve made the paper this talk is based on (pdf) as well as the slides I used during the talk (pdf<img src="http://feeds.feedburner.com/~r/neverletdown/~4/MUyn_Yofgv0" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/03/identifying-process-affordances-nudging-toward-change/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/03/identifying-process-affordances-nudging-toward-change/</feedburner:origLink></item>
		<item>
		<title>Getting Started with Version Control</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/c8JkGvn08Zk/</link>
		<comments>http://neverletdown.net/2010/03/getting-started-with-version-control/#comments</comments>
		<pubDate>Tue, 02 Mar 2010 04:55:19 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[communication]]></category>
		<category><![CDATA[CVS]]></category>
		<category><![CDATA[DRY]]></category>
		<category><![CDATA[pragmatic]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[SVN]]></category>
		<category><![CDATA[version control]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=179</guid>
		<description><![CDATA[I've had to help more than a few teams get their version control systems sorted out over the past few years, and so I thought it would be easier if I just wrote down the philosophies I use for initializing a repository and getting the whole system se]]></description>
			<content:encoded><![CDATA[I've had to help more than a few teams get their version control systems sorted out over the past few years, and so I thought it would be easier if I just wrote down the philosophies I use for initializing a repository and getting the whole system se<img src="http://feeds.feedburner.com/~r/neverletdown/~4/c8JkGvn08Zk" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/03/getting-started-with-version-control/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/03/getting-started-with-version-control/</feedburner:origLink></item>
		<item>
		<title>SWOT vs. Risk Management</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/s7lPoDqkHU4/</link>
		<comments>http://neverletdown.net/2010/02/swot-vs-risk-management/#comments</comments>
		<pubDate>Tue, 16 Feb 2010 04:43:34 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Risk Management]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[swot]]></category>
		<category><![CDATA[team building]]></category>
		<category><![CDATA[threshold of success]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=174</guid>
		<description><![CDATA[I was recently asked by a coworker how software risk management is different from traditional SWOT analysis. SWOT is a technique commonly used for strategic planning where the strengths, weaknesses, opportunities, and threats facing a group are comp]]></description>
			<content:encoded><![CDATA[I was recently asked by a coworker how software risk management is different from traditional SWOT analysis.  SWOT is a technique commonly used for strategic planning where the strengths, weaknesses, opportunities, and threats facing a group are comp<img src="http://feeds.feedburner.com/~r/neverletdown/~4/s7lPoDqkHU4" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/02/swot-vs-risk-management/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/02/swot-vs-risk-management/</feedburner:origLink></item>
		<item>
		<title>Why don’t you use Continuous Integration?</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/A3QvWttxk3c/</link>
		<comments>http://neverletdown.net/2010/02/why-dont-you-use-continuous-integration/#comments</comments>
		<pubDate>Tue, 02 Feb 2010 04:22:15 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[Continuous Integration]]></category>
		<category><![CDATA[Hudson]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[Tools]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=165</guid>
		<description><![CDATA[Everyone has a chore they hate doing. For me it’s cleaning the dishes. I’m a busy guy so I usually don’t get around to cooking and eating dinner until fairly late. Rather than cleaning anything, I stack the dishes in the sink and maybe soak]]></description>
			<content:encoded><![CDATA[Everyone has a chore they hate doing.   For me it’s cleaning the dishes.  I’m a busy guy so I usually don’t get around to cooking and eating dinner until fairly late.  Rather than cleaning anything, I stack the dishes in the sink and maybe soak<img src="http://feeds.feedburner.com/~r/neverletdown/~4/A3QvWttxk3c" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/02/why-dont-you-use-continuous-integration/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/02/why-dont-you-use-continuous-integration/</feedburner:origLink></item>
		<item>
		<title>Threshold of Success</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/gnDlg4psGLw/</link>
		<comments>http://neverletdown.net/2010/01/threshold-of-success/#comments</comments>
		<pubDate>Sat, 16 Jan 2010 04:06:21 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Risk Management]]></category>
		<category><![CDATA[goals]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[project management]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=153</guid>
		<description><![CDATA[When I was a kid my brother and I used to play a game called Make Believe. My favorite variant of the game was simple. Together we would build some kind of fortress and then one person gets the fort and the other person tries to invade the fort. I]]></description>
			<content:encoded><![CDATA[When I was a kid my brother and I used to play a game called Make Believe.  My favorite variant of the game was simple.  Together we would build some kind of fortress and then one person gets the fort and the other person tries to invade the fort.  I<img src="http://feeds.feedburner.com/~r/neverletdown/~4/gnDlg4psGLw" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/01/threshold-of-success/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/01/threshold-of-success/</feedburner:origLink></item>
		<item>
		<title>2010: The Year I Make Contact</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/mgNcHvgiVco/</link>
		<comments>http://neverletdown.net/2010/01/2010-the-year-i-make-contact/#comments</comments>
		<pubDate>Sat, 02 Jan 2010 02:23:39 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Leadership]]></category>
		<category><![CDATA[relationship]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=144</guid>
		<description><![CDATA[Late in the afternoon on December 25, during one of the loudest, howling winter storms I’ve ever experienced we lost power. Normally this wouldn’t be a big deal except I was in a vacation house with 20 other people, basically my wife’s entire]]></description>
			<content:encoded><![CDATA[Late in the afternoon on December 25, during one of the loudest, howling winter storms I’ve ever experienced we lost power.  Normally this wouldn’t be a big deal except I was in a vacation house with 20 other people, basically my wife’s entire <img src="http://feeds.feedburner.com/~r/neverletdown/~4/mgNcHvgiVco" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2010/01/2010-the-year-i-make-contact/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2010/01/2010-the-year-i-make-contact/</feedburner:origLink></item>
		<item>
		<title>The Domestication of Formal Methods</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/6HqMcLLHeFU/</link>
		<comments>http://neverletdown.net/2009/12/the-domestication-of-formal-methods/#comments</comments>
		<pubDate>Tue, 15 Dec 2009 22:28:23 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Formal Methods]]></category>
		<category><![CDATA[affordance]]></category>
		<category><![CDATA[Anthony Hall]]></category>
		<category><![CDATA[Engineering]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[UML]]></category>
		<category><![CDATA[Z]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=131</guid>
		<description><![CDATA[Almost a full year ago, I concluded that formal methods simply aren’t worth the effort: For almost every project in the world, I think formal methods should be generally avoided. Given the option of spending money and time on mathematicians or ex]]></description>
			<content:encoded><![CDATA[Almost a full year ago, I concluded that formal methods simply aren’t worth the effort:
For almost every project in the world, I think formal methods should be generally avoided.  Given the option of spending money and time on mathematicians or ex<img src="http://feeds.feedburner.com/~r/neverletdown/~4/6HqMcLLHeFU" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/12/the-domestication-of-formal-methods/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/12/the-domestication-of-formal-methods/</feedburner:origLink></item>
		<item>
		<title>Groupthink Kills Big Ideas</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/AhIy4LOAl8M/</link>
		<comments>http://neverletdown.net/2009/11/groupthink-kills-big-ideas/#comments</comments>
		<pubDate>Mon, 16 Nov 2009 02:58:00 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Leadership]]></category>
		<category><![CDATA[groupthink]]></category>
		<category><![CDATA[innovation]]></category>
		<category><![CDATA[Kathy Sierra]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=96</guid>
		<description><![CDATA[It’s easy to convince a group of people to follow you when you’ve got a great idea that you’re passionate about. Passion is like a highly communicable virus, easily spreading from one host to another. Something funny happens, though once enou]]></description>
			<content:encoded><![CDATA[It’s easy to convince a group of people to follow you when you’ve got a great idea that you’re passionate about.  Passion is like a highly communicable virus, easily spreading from one host to another.  Something funny happens, though once enou<img src="http://feeds.feedburner.com/~r/neverletdown/~4/AhIy4LOAl8M" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/11/groupthink-kills-big-ideas/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/11/groupthink-kills-big-ideas/</feedburner:origLink></item>
		<item>
		<title>Exploring Archetypes of Architects</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/82AwfcNJbIM/</link>
		<comments>http://neverletdown.net/2009/10/exploring-archetypes-of-architects/#comments</comments>
		<pubDate>Sat, 31 Oct 2009 17:56:17 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Architecture]]></category>
		<category><![CDATA[architect]]></category>
		<category><![CDATA[OOPSLA]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=115</guid>
		<description><![CDATA[During a brainstorming session in a recent OOPSLA workshop I participated in we were discussing what qualities make for a "good" architect in an agile world. I jotted down this list during the discussion based on the group brain dump. Some archetyp]]></description>
			<content:encoded><![CDATA[During a brainstorming session in a recent OOPSLA workshop I participated in we were discussing what qualities make for a "good" architect in an agile world.  I jotted down this list during the discussion based on the group brain dump.  Some archetyp<img src="http://feeds.feedburner.com/~r/neverletdown/~4/82AwfcNJbIM" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/10/exploring-archetypes-of-architects/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/10/exploring-archetypes-of-architects/</feedburner:origLink></item>
		<item>
		<title>Tracking Bugs Better</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/_JJQChWpjIE/</link>
		<comments>http://neverletdown.net/2009/10/tracking-bugs-better/#comments</comments>
		<pubDate>Fri, 16 Oct 2009 03:18:12 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[bug tracking]]></category>
		<category><![CDATA[bugs]]></category>
		<category><![CDATA[defect tracking]]></category>
		<category><![CDATA[defects]]></category>
		<category><![CDATA[process improvement]]></category>
		<category><![CDATA[process tailoring]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[Team Software Process]]></category>
		<category><![CDATA[Testing]]></category>
		<category><![CDATA[XP]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=99</guid>
		<description><![CDATA[Most software processes are light in two areas: quality assurance and process improvement. Most processes prescribe specific techniques for ensuring the production of quality code. XP for example advocates unit testing with TDD, continuous integrat]]></description>
			<content:encoded><![CDATA[Most software processes are light in two areas: quality assurance and process improvement.  Most processes prescribe specific techniques for ensuring the production of quality code.  XP for example advocates unit testing with TDD, continuous integrat<img src="http://feeds.feedburner.com/~r/neverletdown/~4/_JJQChWpjIE" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/10/tracking-bugs-better/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/10/tracking-bugs-better/</feedburner:origLink></item>
		<item>
		<title>Project Signaling</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/SwSyxxDs6oE/</link>
		<comments>http://neverletdown.net/2009/09/project-signaling/#comments</comments>
		<pubDate>Wed, 16 Sep 2009 02:38:49 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Metrics]]></category>
		<category><![CDATA[binary metric]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[signal]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[trigger]]></category>
		<category><![CDATA[tripwire]]></category>
		<category><![CDATA[Van Halen]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=90</guid>
		<description><![CDATA[Van Halen may have known more about project management than most program managers. Van Halen’s legendary "No Brown M&#38;Ms Rider" is simultaneously the greatest example of rock star excess and project signaling I’ve ever seen. As David Lee Rot]]></description>
			<content:encoded><![CDATA[Van Halen may have known more about project management than most program managers.  Van Halen’s legendary "No Brown M&amp;Ms Rider" is simultaneously the greatest example of rock star excess and project signaling I’ve ever seen.  As David Lee Rot<img src="http://feeds.feedburner.com/~r/neverletdown/~4/SwSyxxDs6oE" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/09/project-signaling/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/09/project-signaling/</feedburner:origLink></item>
		<item>
		<title>Binary is a Metric Too</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/zT4dOCe1b1g/</link>
		<comments>http://neverletdown.net/2009/09/binary-is-a-metric-too/#comments</comments>
		<pubDate>Tue, 01 Sep 2009 21:07:51 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Engineering]]></category>
		<category><![CDATA[Metrics]]></category>
		<category><![CDATA[anlaysis]]></category>
		<category><![CDATA[control]]></category>
		<category><![CDATA[data]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[measurement]]></category>
		<category><![CDATA[measures]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[Tom DeMarco]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=76</guid>
		<description><![CDATA[Software developers are, in their heart of hearts, dataphiles - people who are absolutely in love with data. When was the last time you had a passionate discussion about frame rates, hardware benchmarks, gadget specs, sports statistics, dungeons and]]></description>
			<content:encoded><![CDATA[Software developers are, in their heart of hearts, dataphiles - people who are absolutely in love with data.  When was the last time you had a passionate discussion about frame rates, hardware benchmarks, gadget specs, sports statistics, dungeons and<img src="http://feeds.feedburner.com/~r/neverletdown/~4/zT4dOCe1b1g" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/09/binary-is-a-metric-too/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/09/binary-is-a-metric-too/</feedburner:origLink></item>
		<item>
		<title>Software Craftsmanship: Engineering by Coincidence</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/UF1NfLYz7es/</link>
		<comments>http://neverletdown.net/2009/08/software-craftsmanship-engineering-by-coincidence/#comments</comments>
		<pubDate>Sun, 16 Aug 2009 00:26:50 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Engineering]]></category>
		<category><![CDATA[Jeff Atwood]]></category>
		<category><![CDATA[Metrics]]></category>
		<category><![CDATA[Process]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[Tom DeMarco]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=69</guid>
		<description><![CDATA[I was extremely disappointed to read a recent article on Coding Horror reflecting on an IEEE editorial written by Tom DeMarco. If you have not already, please read Tom DeMarco’s article now. It’s only two pages and it’s well written. With]]></description>
			<content:encoded><![CDATA[I was extremely disappointed to read a recent article on Coding Horror reflecting on an IEEE editorial written by Tom DeMarco.  If you have not already, please read Tom DeMarco’s article now.  It’s only two pages and it’s well written.

With <img src="http://feeds.feedburner.com/~r/neverletdown/~4/UF1NfLYz7es" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/08/software-craftsmanship-engineering-by-coincidence/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/08/software-craftsmanship-engineering-by-coincidence/</feedburner:origLink></item>
		<item>
		<title>Relationships Matter</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/epXjdb71e34/</link>
		<comments>http://neverletdown.net/2009/07/relationships-matter/#comments</comments>
		<pubDate>Tue, 14 Jul 2009 03:41:01 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Leadership]]></category>
		<category><![CDATA[Kathy Sierra]]></category>
		<category><![CDATA[relationship]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=61</guid>
		<description><![CDATA[Building a great software product is only half the battle. The relationship the user builds with your software has the single greatest influence on how awesome that software is. Sorry. It’s not the language the software is written in. It’s no]]></description>
			<content:encoded><![CDATA[Building a great software product is only half the battle.  The relationship the user builds with your software has the single greatest influence on how awesome that software is.  Sorry.  It’s not the language the software is written in.  It’s no<img src="http://feeds.feedburner.com/~r/neverletdown/~4/epXjdb71e34" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/07/relationships-matter/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/07/relationships-matter/</feedburner:origLink></item>
		<item>
		<title>Kenny Rogers’ Guide to Software Process Improvement</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/u6LGRvlQWDE/</link>
		<comments>http://neverletdown.net/2009/06/kenny-rogers-guide-to-software-process-improvement/#comments</comments>
		<pubDate>Sun, 14 Jun 2009 00:37:26 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[CMM]]></category>
		<category><![CDATA[CMMI]]></category>
		<category><![CDATA[process improvement]]></category>
		<category><![CDATA[ROI]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=50</guid>
		<description><![CDATA[Process improvement is a tricky mistress.  Usually it’s sufficient to feel that something can be done better, but often, especially for larger organizations or folks looking for higher CMMI rankings, it’s necessary to quantify improvements in te]]></description>
			<content:encoded><![CDATA[Process improvement is a tricky mistress.  Usually it’s sufficient to feel that something can be done better, but often, especially for larger organizations or folks looking for higher CMMI rankings, it’s necessary to quantify improvements in te<img src="http://feeds.feedburner.com/~r/neverletdown/~4/u6LGRvlQWDE" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/06/kenny-rogers-guide-to-software-process-improvement/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/06/kenny-rogers-guide-to-software-process-improvement/</feedburner:origLink></item>
		<item>
		<title>Software Engineering: Art or Engineering?</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/Sm-ZBHDOjxs/</link>
		<comments>http://neverletdown.net/2009/05/software-engineering-art-or-engineering/#comments</comments>
		<pubDate>Wed, 13 May 2009 22:59:02 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Engineering]]></category>
		<category><![CDATA[art]]></category>
		<category><![CDATA[creativity]]></category>
		<category><![CDATA[education]]></category>
		<category><![CDATA[opinion]]></category>
		<category><![CDATA[software engineering]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=43</guid>
		<description><![CDATA[For some reason software engineers and others who deal with software love sitting around debating whether software engineering is more art or engineering. Part of the problem comes from how software engineering came to be, the term assigned as more]]></description>
			<content:encoded><![CDATA[For some reason software engineers and others who deal with software love sitting around debating whether software engineering is more art or engineering.  Part of the problem comes from how software engineering came to be, the term assigned as more <img src="http://feeds.feedburner.com/~r/neverletdown/~4/Sm-ZBHDOjxs" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/05/software-engineering-art-or-engineering/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/05/software-engineering-art-or-engineering/</feedburner:origLink></item>
		<item>
		<title>Securing the Internet</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/dHuyTA1bmRQ/</link>
		<comments>http://neverletdown.net/2009/04/securing-the-internet/#comments</comments>
		<pubDate>Tue, 14 Apr 2009 03:49:43 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Security]]></category>
		<category><![CDATA[CERT]]></category>
		<category><![CDATA[conference]]></category>
		<category><![CDATA[internet]]></category>
		<category><![CDATA[OpenId]]></category>
		<category><![CDATA[Scott Charney]]></category>
		<category><![CDATA[Vinton Cerf]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=37</guid>
		<description><![CDATA[Over Spring break I was fortunate to receive an invitation to the exclusive CERT (Computer Emergency Response Team) 2009 Technical Symposium.  The symposium was held in celebration of the twentieth anniversary of CERT but the main theme of the sympo]]></description>
			<content:encoded><![CDATA[Over Spring break I was fortunate to receive an invitation to the exclusive CERT (Computer Emergency Response Team) 2009 Technical Symposium.  The symposium was held in celebration of the twentieth anniversary of CERT but the main theme of the sympo<img src="http://feeds.feedburner.com/~r/neverletdown/~4/dHuyTA1bmRQ" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/04/securing-the-internet/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/04/securing-the-internet/</feedburner:origLink></item>
		<item>
		<title>Process Affordances: Ignore at Your own Peril</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/BYQWbqNo3m8/</link>
		<comments>http://neverletdown.net/2009/03/process-affordances-ignore-at-your-own-peril/#comments</comments>
		<pubDate>Fri, 13 Mar 2009 21:15:07 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[affordance]]></category>
		<category><![CDATA[Carnegie Mellon]]></category>
		<category><![CDATA[Donald Norman]]></category>
		<category><![CDATA[nudge]]></category>
		<category><![CDATA[planning]]></category>
		<category><![CDATA[postmortem]]></category>
		<category><![CDATA[Scrum]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[studio]]></category>
		<category><![CDATA[tracking]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=26</guid>
		<description><![CDATA[The Amsterdam airport was able to reduce the amount of urine "spillage" that hit the men's room floor by 80% simply by etching a life-like image of a fly near the urinals' drains. The fly was specifically engineered into the urinals to alter gentlem]]></description>
			<content:encoded><![CDATA[The Amsterdam airport was able to reduce the amount of urine "spillage" that hit the men's room floor by 80% simply by etching a life-like image of a fly near the urinals' drains.  The fly was specifically engineered into the urinals to alter gentlem<img src="http://feeds.feedburner.com/~r/neverletdown/~4/BYQWbqNo3m8" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/03/process-affordances-ignore-at-your-own-peril/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/03/process-affordances-ignore-at-your-own-peril/</feedburner:origLink></item>
		<item>
		<title>Applying Leadership Styles</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/2LEe0dj_y7g/</link>
		<comments>http://neverletdown.net/2009/02/applying-leadership-styles/#comments</comments>
		<pubDate>Fri, 13 Feb 2009 22:56:13 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Leadership]]></category>
		<category><![CDATA[communication]]></category>
		<category><![CDATA[Daniel Goleman]]></category>
		<category><![CDATA[leadership styles]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[team building]]></category>
		<category><![CDATA[teamicide]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=14</guid>
		<description><![CDATA[The setting is a small library filled with various books on software engineering. Five people are sitting around a single, small table, the room overcrowded with the group. The Square Root team is reviewing the mid-semester presentation I threw tog]]></description>
			<content:encoded><![CDATA[The setting is a small library filled with various books on software engineering.  Five people are sitting around a single, small table, the room overcrowded with the group.  The Square Root team is reviewing the mid-semester presentation I threw tog<img src="http://feeds.feedburner.com/~r/neverletdown/~4/2LEe0dj_y7g" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/02/applying-leadership-styles/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/02/applying-leadership-styles/</feedburner:origLink></item>
		<item>
		<title>Thoughts on Formal Methods in Software Engineering</title>
		<link>http://feedproxy.google.com/~r/neverletdown/~3/oPr9pw_Ik10/</link>
		<comments>http://neverletdown.net/2009/01/thoughts-on-formal-methods-in-software-engineering/#comments</comments>
		<pubDate>Wed, 14 Jan 2009 03:30:28 +0000</pubDate>
		<dc:creator>Michael Keeling</dc:creator>
				<category><![CDATA[Formal Methods]]></category>
		<category><![CDATA[FSP]]></category>
		<category><![CDATA[OCL]]></category>
		<category><![CDATA[Petri Nets]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[UML]]></category>
		<category><![CDATA[Z]]></category>

		<guid isPermaLink="false">http://neverletdown.net/?p=4</guid>
		<description><![CDATA[Are formal methods in software engineering really all they are cracked up to be? First, let me clarify what I mean by formal methods.  Formal methods use mathematical representations of software to formally prove that the software behaves as expe]]></description>
			<content:encoded><![CDATA[Are formal methods in software engineering really all they are cracked up to be?

First, let me clarify what I mean by formal methods.  Formal methods use mathematical representations of software to formally prove that the software behaves as expe<img src="http://feeds.feedburner.com/~r/neverletdown/~4/oPr9pw_Ik10" height="1" width="1"/>]]></content:encoded>
			<wfw:commentRss>http://neverletdown.net/2009/01/thoughts-on-formal-methods-in-software-engineering/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<feedburner:origLink>http://neverletdown.net/2009/01/thoughts-on-formal-methods-in-software-engineering/</feedburner:origLink></item>
	</channel>
</rss><!-- Dynamic page generated in 1.015 seconds. --><!-- Cached page generated by WP-Super-Cache on 2012-01-31 13:09:38 --><!-- Compression = gzip -->

