<?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: Software design and specification and making movies</title>
	<atom:link href="http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/</link>
	<description>Software product success.</description>
	<lastBuildDate>Sun, 12 Feb 2012 19:10:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Andy</title>
		<link>http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/comment-page-1/#comment-548</link>
		<dc:creator>Andy</dc:creator>
		<pubDate>Thu, 23 Mar 2006 14:50:55 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/#comment-548</guid>
		<description>If it is necessary to make Cooper&#039;s analogy fit Agile then its worth bearing in mind that Agile development often has phases.  In XP for instance before code written both the exploration and planning phases are performed.  However deciding what to do, doing it and delivering it do not advance software process much.  You just end up stretching the semantics of each to make it fit.  For me where these analogies are useful is to affect a change in emphasis.  The idea that software is like the movie industry evokes a different way of thinking about product design; a way of thinking that is better suited to interaction design.  However if you are in the guts of the system debugging a very intricate issue, another analogy might be best fit.  It seems to me such analogies are used to get people thinking along the same lines, not to suggest that one model should fit all.  From one role software might look like a film, from another role it looks like something else. Reminds me of the story of the &lt;a href=&quot;http://www.kheper.net/topics/blind_men_and_elephant/&quot; rel=&quot;nofollow&quot;&gt;blind-men and the elephant&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>If it is necessary to make Cooper&#8217;s analogy fit Agile then its worth bearing in mind that Agile development often has phases.  In XP for instance before code written both the exploration and planning phases are performed.  However deciding what to do, doing it and delivering it do not advance software process much.  You just end up stretching the semantics of each to make it fit.  For me where these analogies are useful is to affect a change in emphasis.  The idea that software is like the movie industry evokes a different way of thinking about product design; a way of thinking that is better suited to interaction design.  However if you are in the guts of the system debugging a very intricate issue, another analogy might be best fit.  It seems to me such analogies are used to get people thinking along the same lines, not to suggest that one model should fit all.  From one role software might look like a film, from another role it looks like something else. Reminds me of the story of the <a href="http://www.kheper.net/topics/blind_men_and_elephant/" rel="nofollow">blind-men and the elephant</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nils</title>
		<link>http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/comment-page-1/#comment-516</link>
		<dc:creator>Nils</dc:creator>
		<pubDate>Wed, 22 Mar 2006 01:01:24 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/#comment-516</guid>
		<description>Some problems with the &quot;software-as-movie-production&quot; analogy:

1. Movie projects are even less successful on average than software projects. 

2. Most successful movies are the result not of a requirements gathering process, but of an auteur&#039;s vision (Chinatown, for example), or the vision of a handful of people (Casablanca). 

3. In today&#039;s market, a huge part of the overall budget of a movie is pre-release marketing. A blockbuster, with a production budget of $100 million, will often have a $40 million marketing budget. There&#039;s simply no analogy in software products. 

Bottom line, the whole relationship of the production to the user/client is completely different between software and movies. The point that movie makers spend a huge amount of time on pre-production (although a relatively small amount of their budget) is excellent, but I don&#039;t think there&#039;s too much more to learn from the analogy than &quot;figuring out what you want to do at the beginning of your project is a good thing.&quot;</description>
		<content:encoded><![CDATA[<p>Some problems with the &#8220;software-as-movie-production&#8221; analogy:</p>
<p>1. Movie projects are even less successful on average than software projects. </p>
<p>2. Most successful movies are the result not of a requirements gathering process, but of an auteur&#8217;s vision (Chinatown, for example), or the vision of a handful of people (Casablanca). </p>
<p>3. In today&#8217;s market, a huge part of the overall budget of a movie is pre-release marketing. A blockbuster, with a production budget of $100 million, will often have a $40 million marketing budget. There&#8217;s simply no analogy in software products. </p>
<p>Bottom line, the whole relationship of the production to the user/client is completely different between software and movies. The point that movie makers spend a huge amount of time on pre-production (although a relatively small amount of their budget) is excellent, but I don&#8217;t think there&#8217;s too much more to learn from the analogy than &#8220;figuring out what you want to do at the beginning of your project is a good thing.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/comment-page-1/#comment-506</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Tue, 21 Mar 2006 14:20:21 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/#comment-506</guid>
		<description>Hey Rich, thanks for reading and commenting!

I had to reset my &quot;who are the users?&quot; perspective when reading Cooper&#039;s book.  He contends that while there may be several users (personas) who use the software, you must design it specifically for one or at most two primary users.
He points out that you can&#039;t be all things to all people, you end up with a homogenized application - either watered-down to the point of uselessness, or bloated-up to the point of frustration for all (all except other programmers, that is).  I think he&#039;s exactly right.
Some movies try to appeal to cross-over audiences (a fight scene in a love story) to get economies of scale.  The fight scene is unappealing to the moveie&#039;s target audience, and likely not enough for the cross-over people.  Great movies stay true to their audiences and don&#039;t cross over at all.
I&#039;ve come to realize that the same holds true for software.  &quot;Universal appeal&quot; should never be a goal for most software.</description>
		<content:encoded><![CDATA[<p>Hey Rich, thanks for reading and commenting!</p>
<p>I had to reset my &#8220;who are the users?&#8221; perspective when reading Cooper&#8217;s book.  He contends that while there may be several users (personas) who use the software, you must design it specifically for one or at most two primary users.<br />
He points out that you can&#8217;t be all things to all people, you end up with a homogenized application &#8211; either watered-down to the point of uselessness, or bloated-up to the point of frustration for all (all except other programmers, that is).  I think he&#8217;s exactly right.<br />
Some movies try to appeal to cross-over audiences (a fight scene in a love story) to get economies of scale.  The fight scene is unappealing to the moveie&#8217;s target audience, and likely not enough for the cross-over people.  Great movies stay true to their audiences and don&#8217;t cross over at all.<br />
I&#8217;ve come to realize that the same holds true for software.  &#8220;Universal appeal&#8221; should never be a goal for most software.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rich</title>
		<link>http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/comment-page-1/#comment-504</link>
		<dc:creator>Rich</dc:creator>
		<pubDate>Tue, 21 Mar 2006 13:59:50 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/03/20/software-design-and-specification-and-making-movies/#comment-504</guid>
		<description>I suppose the big problem with the movie-software analogy is that the views of the end user in movies tend to be very varied. Very few movies manage to please the majority of people and their expectations even when they are the intended audience...</description>
		<content:encoded><![CDATA[<p>I suppose the big problem with the movie-software analogy is that the views of the end user in movies tend to be very varied. Very few movies manage to please the majority of people and their expectations even when they are the intended audience&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

