<?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: Trend of the decade: decentralized process</title>
	<atom:link href="http://rc3.org/2009/12/26/trend-of-the-decade-decentralized-process/feed/" rel="self" type="application/rss+xml" />
	<link>http://rc3.org/2009/12/26/trend-of-the-decade-decentralized-process/</link>
	<description>Strong opinions weakly held</description>
	<lastBuildDate>Fri, 10 Feb 2012 14:59:55 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Jacob Davies</title>
		<link>http://rc3.org/2009/12/26/trend-of-the-decade-decentralized-process/comment-page-1/#comment-7614</link>
		<dc:creator>Jacob Davies</dc:creator>
		<pubDate>Mon, 28 Dec 2009 18:01:01 +0000</pubDate>
		<guid isPermaLink="false">http://rc3.org/?p=10448#comment-7614</guid>
		<description>&lt;p&gt;12 years ago the Software Engineering courses in my CS degree were concerned mostly with process, but the semi-official message of the classes was &quot;This is an annoying waste of time you will be forced to participate in that will help neither you nor your managers&quot;.&lt;/p&gt;

&lt;p&gt;The problem is that cargo-cult imitation of engineering practices is fine IF you have the time to do it - software developed that way will be extremely reliable but it will take forever. So, for instance, the software for the Space Shuttle is famous as an example of something developed that way.&lt;/p&gt;

&lt;p&gt;XP said hey wait a minute, we&#039;re computer programmers and what we&#039;re testing is software, it is a mathematical object and it is malleable, we can reconstruct it using mathematical transforms that do not change the functioning of it, just the structure; it is fast to run and we can test it without physically constructing anything; we&#039;re smart, we can communicate concepts among ourselves without long meetings; we know that without regular releases we can get far off track.&lt;/p&gt;

&lt;p&gt;Actually XP didn&#039;t really tell me or the people I talked with many of those things. We already knew them. But it did codify them.&lt;/p&gt;

&lt;p&gt;Religious adherence to process in situations where innovation is the goal is never going to work. What XP (etc) did was find some things that actually do work in that situation and put a stamp of approval on it.&lt;/p&gt;

&lt;p&gt;In general the world of software is far too attached to formality, cargo-cult imitation of either formal mathematics or mechanical engineering. Those of us exposed to Perl and shell scripting and subsequent developments understand that it doesn&#039;t have to be like that, but conventional wisdom about what is or is not acceptable still prevails.&lt;/p&gt;

&lt;p&gt;I&#039;ve been working mostly on my own for years, and the most valuable thing for me has been the arrival of refactoring tools. (These are especially good if you&#039;re working on your own!) I do a fair amount of automated testing but the majority of what I&#039;ve been doing has been what you might call exploratory, working out ideas into code and then refining them, so test-first doesn&#039;t really fit. I use a ticket tracker and aim for (don&#039;t always achieve) continuous releasing.&lt;/p&gt;

&lt;p&gt;As much as the rise of lightweight process has been the apparent demise of heavyweight process at least in the world I deal with. If the choice is running code or your own weight in paper specifications, well, ever tried selling a specification? Right.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>12 years ago the Software Engineering courses in my CS degree were concerned mostly with process, but the semi-official message of the classes was &#8220;This is an annoying waste of time you will be forced to participate in that will help neither you nor your managers&#8221;.</p>

<p>The problem is that cargo-cult imitation of engineering practices is fine IF you have the time to do it &#8211; software developed that way will be extremely reliable but it will take forever. So, for instance, the software for the Space Shuttle is famous as an example of something developed that way.</p>

<p>XP said hey wait a minute, we&#8217;re computer programmers and what we&#8217;re testing is software, it is a mathematical object and it is malleable, we can reconstruct it using mathematical transforms that do not change the functioning of it, just the structure; it is fast to run and we can test it without physically constructing anything; we&#8217;re smart, we can communicate concepts among ourselves without long meetings; we know that without regular releases we can get far off track.</p>

<p>Actually XP didn&#8217;t really tell me or the people I talked with many of those things. We already knew them. But it did codify them.</p>

<p>Religious adherence to process in situations where innovation is the goal is never going to work. What XP (etc) did was find some things that actually do work in that situation and put a stamp of approval on it.</p>

<p>In general the world of software is far too attached to formality, cargo-cult imitation of either formal mathematics or mechanical engineering. Those of us exposed to Perl and shell scripting and subsequent developments understand that it doesn&#8217;t have to be like that, but conventional wisdom about what is or is not acceptable still prevails.</p>

<p>I&#8217;ve been working mostly on my own for years, and the most valuable thing for me has been the arrival of refactoring tools. (These are especially good if you&#8217;re working on your own!) I do a fair amount of automated testing but the majority of what I&#8217;ve been doing has been what you might call exploratory, working out ideas into code and then refining them, so test-first doesn&#8217;t really fit. I use a ticket tracker and aim for (don&#8217;t always achieve) continuous releasing.</p>

<p>As much as the rise of lightweight process has been the apparent demise of heavyweight process at least in the world I deal with. If the choice is running code or your own weight in paper specifications, well, ever tried selling a specification? Right.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Roberto</title>
		<link>http://rc3.org/2009/12/26/trend-of-the-decade-decentralized-process/comment-page-1/#comment-7606</link>
		<dc:creator>Mike Roberto</dc:creator>
		<pubDate>Sun, 27 Dec 2009 03:08:14 +0000</pubDate>
		<guid isPermaLink="false">http://rc3.org/?p=10448#comment-7606</guid>
		<description>&lt;p&gt;Great article - I totally agree on all points, especially the role that blogging has taken.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Great article &#8211; I totally agree on all points, especially the role that blogging has taken.</p>]]></content:encoded>
	</item>
</channel>
</rss>

