<?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: The Problem With How Software is Developed Today</title>
	<atom:link href="http://www.scottkelby.com/blog/2008/archives/1422/feed" rel="self" type="application/rss+xml" />
	<link>http://www.scottkelby.com/blog/2008/archives/1422</link>
	<description>Scoops, tips and comments published exclusively for friends of Scott Kelby</description>
	<lastBuildDate>Thu, 18 Mar 2010 05:16:27 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ken Elliott</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62990</link>
		<dc:creator>Ken Elliott</dc:creator>
		<pubDate>Wed, 04 Jun 2008 13:46:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62990</guid>
		<description>I don&#039;t like the idea of Adobe asking ALL their customer what they want.  The signal-to-noise ratio would make this useless.

The best example of software development is Robert McNeel and Associates Rhino (www.rhino3d.com).  They pioneered completely open development and had Rhino in beta for 7 years before they released it.  They hosted a forum where users would support one another.  Users would download new versions of Rhino that ran for 90 days.  Every 90 days you&#039;d simply download another version.  The development team would watch the conversations that took place and steer the platform development to support the needs of the users.  And they rewrote the app from scratch more than once.

I believe/hope that Adobe is using the lessons of McNeel in developing LightRoom.  I don&#039;t want a product designed by committee, like the Pontiac Aztec.  I want a product designed by someone with a vision, like Enzo Ferrari did.  Ferrari created the car HE wanted, with input by people he respected (F1 drivers).</description>
		<content:encoded><![CDATA[<p>I don&#8217;t like the idea of Adobe asking ALL their customer what they want.  The signal-to-noise ratio would make this useless.</p>
<p>The best example of software development is Robert McNeel and Associates Rhino (www.rhino3d.com).  They pioneered completely open development and had Rhino in beta for 7 years before they released it.  They hosted a forum where users would support one another.  Users would download new versions of Rhino that ran for 90 days.  Every 90 days you&#8217;d simply download another version.  The development team would watch the conversations that took place and steer the platform development to support the needs of the users.  And they rewrote the app from scratch more than once.</p>
<p>I believe/hope that Adobe is using the lessons of McNeel in developing LightRoom.  I don&#8217;t want a product designed by committee, like the Pontiac Aztec.  I want a product designed by someone with a vision, like Enzo Ferrari did.  Ferrari created the car HE wanted, with input by people he respected (F1 drivers).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62858</link>
		<dc:creator>Sean</dc:creator>
		<pubDate>Tue, 03 Jun 2008 22:13:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62858</guid>
		<description>I like this analogy.  

It would be even closer to the truth if the waiter snatched the menu out of my hands when tried to order and said &quot;Aha, your accent tells me that you&#039;re not from around here.  You have to order from the specials menu.  It&#039;s exactly the same as the menu you were just looking at and comes from the same kitchen but it&#039;s twice the price!&quot;.</description>
		<content:encoded><![CDATA[<p>I like this analogy.  </p>
<p>It would be even closer to the truth if the waiter snatched the menu out of my hands when tried to order and said &#8220;Aha, your accent tells me that you&#8217;re not from around here.  You have to order from the specials menu.  It&#8217;s exactly the same as the menu you were just looking at and comes from the same kitchen but it&#8217;s twice the price!&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62426</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Mon, 02 Jun 2008 05:24:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62426</guid>
		<description>I&#039;ve worked in the software industry for many years, and here are some home truths.

1. All commercial software is created by programmers who almost never use the software. They don&#039;t care what dishes are on the menu and they don&#039;t care where the fork is. They do what they&#039;re told and they build the restaurant the way they&#039;re told to build it. If those instructions result in a confusing restaurant, that&#039;s not their problem. Hell, if they&#039;re in a big company they might not even KNOW they&#039;re working on part of a restaurant.

2. The instructions are given to the programmers are inevitably driven by the marketing department. Newsflash, the people in marketing don&#039;t use the software either. Not only do they not use the software, they don&#039;t understand the technology. All they know is &quot;what&#039;s hot right now&quot;. 

Most commercial software is created based on the instructions of ignorant people passed on to indifferent people. That&#039;s why most of it is crap.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve worked in the software industry for many years, and here are some home truths.</p>
<p>1. All commercial software is created by programmers who almost never use the software. They don&#8217;t care what dishes are on the menu and they don&#8217;t care where the fork is. They do what they&#8217;re told and they build the restaurant the way they&#8217;re told to build it. If those instructions result in a confusing restaurant, that&#8217;s not their problem. Hell, if they&#8217;re in a big company they might not even KNOW they&#8217;re working on part of a restaurant.</p>
<p>2. The instructions are given to the programmers are inevitably driven by the marketing department. Newsflash, the people in marketing don&#8217;t use the software either. Not only do they not use the software, they don&#8217;t understand the technology. All they know is &#8220;what&#8217;s hot right now&#8221;. </p>
<p>Most commercial software is created based on the instructions of ignorant people passed on to indifferent people. That&#8217;s why most of it is crap.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ned Leary</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62330</link>
		<dc:creator>Ned Leary</dc:creator>
		<pubDate>Sun, 01 Jun 2008 13:54:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62330</guid>
		<description>Heck of a topic...heck of a thread...My studio opens in a week...stop by sometime...you helped get me going...thanks my friend

The Blurry One</description>
		<content:encoded><![CDATA[<p>Heck of a topic&#8230;heck of a thread&#8230;My studio opens in a week&#8230;stop by sometime&#8230;you helped get me going&#8230;thanks my friend</p>
<p>The Blurry One</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ron</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62283</link>
		<dc:creator>Ron</dc:creator>
		<pubDate>Sun, 01 Jun 2008 06:39:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62283</guid>
		<description>I work for a major software company and odds are you are using at least one of our products. I can tell you that we build our products entirely based on customer feedback, but the problem is that when you have 500,000+ customers, you can&#039;t take every suggestion and wish and make it a reality. Shipping is a feature too, so you have to take the ones that are requested most frequently and evaluate the cost/benefit of those features and decide which can be implemented in a reasonable time with the available resources at hand. Any company that doesn&#039;t build software based on user input simply doesn&#039;t survive in this industry for very long, but the problem will always remain that what is a great feature for one person will be a pain in the a$$ for another. If you cater to the beginner you make the power user unhappy, and vice versa. So what do you do? You try to strike a balance and go back to the &quot;most bang for the buck&quot; way of choosing your features for the next version. 

While people like to complain and say that companies like mine don&#039;t listen, the fact is that I&#039;ve seen repeated instances where one customers gripe/suggestion take priority over all of the developers and program managers input. As a consumer, at least with my company for the nearly 14 years I&#039;ve been there, this is how it works. I don&#039;t believe Adobe follows this policy to the same extent we do, but they have to be doing a little bit of listening to their customers otherwise they couldn&#039;t continue to create compelling new releases that cause people to pay the huge upgrade fees they charge.</description>
		<content:encoded><![CDATA[<p>I work for a major software company and odds are you are using at least one of our products. I can tell you that we build our products entirely based on customer feedback, but the problem is that when you have 500,000+ customers, you can&#8217;t take every suggestion and wish and make it a reality. Shipping is a feature too, so you have to take the ones that are requested most frequently and evaluate the cost/benefit of those features and decide which can be implemented in a reasonable time with the available resources at hand. Any company that doesn&#8217;t build software based on user input simply doesn&#8217;t survive in this industry for very long, but the problem will always remain that what is a great feature for one person will be a pain in the a$$ for another. If you cater to the beginner you make the power user unhappy, and vice versa. So what do you do? You try to strike a balance and go back to the &#8220;most bang for the buck&#8221; way of choosing your features for the next version. </p>
<p>While people like to complain and say that companies like mine don&#8217;t listen, the fact is that I&#8217;ve seen repeated instances where one customers gripe/suggestion take priority over all of the developers and program managers input. As a consumer, at least with my company for the nearly 14 years I&#8217;ve been there, this is how it works. I don&#8217;t believe Adobe follows this policy to the same extent we do, but they have to be doing a little bit of listening to their customers otherwise they couldn&#8217;t continue to create compelling new releases that cause people to pay the huge upgrade fees they charge.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Wiacek</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62268</link>
		<dc:creator>Mike Wiacek</dc:creator>
		<pubDate>Sun, 01 Jun 2008 03:59:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62268</guid>
		<description>Scott, this is a bit off topic, but I know you actively read your blog comments and figured this is a good place to ask.  I was trying tom come up with a photoshop action that would add a mat to an image and leave double the room at the bottom for a name plate.  I&#039;d like to have something that works for an image regardless of aspect ratio, but I&#039;ve been unable to do that so far.  An square image makes it easy, but a 4:3 is much trickier.  Is there a way to do this with 1 action?  Or am I going to have to have several actions, one for each aspect ratio.  Cheers!</description>
		<content:encoded><![CDATA[<p>Scott, this is a bit off topic, but I know you actively read your blog comments and figured this is a good place to ask.  I was trying tom come up with a photoshop action that would add a mat to an image and leave double the room at the bottom for a name plate.  I&#8217;d like to have something that works for an image regardless of aspect ratio, but I&#8217;ve been unable to do that so far.  An square image makes it easy, but a 4:3 is much trickier.  Is there a way to do this with 1 action?  Or am I going to have to have several actions, one for each aspect ratio.  Cheers!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62232</link>
		<dc:creator>Ken</dc:creator>
		<pubDate>Sat, 31 May 2008 22:55:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62232</guid>
		<description>Lots of good comments above.  I&#039;m in the camp that thinks Adobe is doing a pretty darn good job with their products already.  I mean, they are the biggest company in their field and yet most people still really like their products (unlike Microsoft) and have given us many tools over the years most people wouldn&#039;t even think of, but now can&#039;t live without.  I think they already involve the consumer quite a bit with their beta programs.</description>
		<content:encoded><![CDATA[<p>Lots of good comments above.  I&#8217;m in the camp that thinks Adobe is doing a pretty darn good job with their products already.  I mean, they are the biggest company in their field and yet most people still really like their products (unlike Microsoft) and have given us many tools over the years most people wouldn&#8217;t even think of, but now can&#8217;t live without.  I think they already involve the consumer quite a bit with their beta programs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Barclay</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62089</link>
		<dc:creator>Kevin Barclay</dc:creator>
		<pubDate>Sat, 31 May 2008 04:45:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62089</guid>
		<description>So - here&#039;s the deal - I loved the analogy, truly made me laugh.

I am not surprised that some software developers are pissed about this, and the &quot;Scott Kelby&quot; example doesn&#039;t fly with me.  Don&#039;t get me wrong, I wouldn&#039;t be half the photographer I am without Scott - but industry can&#039;t use the guru response.  Here&#039;s what I mean....   there are relatively few people in the guru category that developers can gear changes to.  

However, all being said, gurus like Mr. Kelby are the expertise that we all draw from.

So....all aaid - software developers tale note- release a Beta - give lots of opportunities for feedback and develop some metrics to gain the knowledge of the masses..............

and listen to the Masters like Scott , but also listen to those who Scott gives the greatest advice to!</description>
		<content:encoded><![CDATA[<p>So &#8211; here&#8217;s the deal &#8211; I loved the analogy, truly made me laugh.</p>
<p>I am not surprised that some software developers are pissed about this, and the &#8220;Scott Kelby&#8221; example doesn&#8217;t fly with me.  Don&#8217;t get me wrong, I wouldn&#8217;t be half the photographer I am without Scott &#8211; but industry can&#8217;t use the guru response.  Here&#8217;s what I mean&#8230;.   there are relatively few people in the guru category that developers can gear changes to.  </p>
<p>However, all being said, gurus like Mr. Kelby are the expertise that we all draw from.</p>
<p>So&#8230;.all aaid &#8211; software developers tale note- release a Beta &#8211; give lots of opportunities for feedback and develop some metrics to gain the knowledge of the masses&#8230;&#8230;&#8230;&#8230;..</p>
<p>and listen to the Masters like Scott , but also listen to those who Scott gives the greatest advice to!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Neil</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62044</link>
		<dc:creator>Neil</dc:creator>
		<pubDate>Fri, 30 May 2008 23:32:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62044</guid>
		<description>There are many issues regarding software development. I&#039;m a senior software developer for a top 10 financial company in our field. I can tell you that politics plays a large roll in what gets developed. The politics can be from internal people who have to push their pet projects through or politics with a big customer who demands a certain feature even if it breaks what the majority needs.

Theoretically, Agile software development can deal with this but the logistics of producing a product that will be used by millions is very difficult. Most companies refuse to spend the time or money in extensive user testing and proper UX planning. And realize that all development comes with the idea that some bugs are more &quot;acceptable&quot; and can be released anyway. It has to do with the cost/benefit ratio of the features being released.

There are no easy solutions but from this developer&#039;s perspective I think one thing would help: attention to quality. The ideal of craftsmanship has eroded over the decades to being non-existent. I would like to see a revival in caring about what we work on and wanting it to be the best.</description>
		<content:encoded><![CDATA[<p>There are many issues regarding software development. I&#8217;m a senior software developer for a top 10 financial company in our field. I can tell you that politics plays a large roll in what gets developed. The politics can be from internal people who have to push their pet projects through or politics with a big customer who demands a certain feature even if it breaks what the majority needs.</p>
<p>Theoretically, Agile software development can deal with this but the logistics of producing a product that will be used by millions is very difficult. Most companies refuse to spend the time or money in extensive user testing and proper UX planning. And realize that all development comes with the idea that some bugs are more &#8220;acceptable&#8221; and can be released anyway. It has to do with the cost/benefit ratio of the features being released.</p>
<p>There are no easy solutions but from this developer&#8217;s perspective I think one thing would help: attention to quality. The ideal of craftsmanship has eroded over the decades to being non-existent. I would like to see a revival in caring about what we work on and wanting it to be the best.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jermaine Beckley</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62037</link>
		<dc:creator>Jermaine Beckley</dc:creator>
		<pubDate>Fri, 30 May 2008 21:59:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62037</guid>
		<description>Well I personally think Adobe is doing just fine and should hold out longer than 18 months for a new release. I just upgraded to CS3 about a month and a half ago. I waited because I wanted to make sure there weren&#039;t any bugs like Apple did with Leopard or Canon did with the Mark III. Now I feel like I really didn&#039;t need the upgrade because I hardly use any of the new features and I mostly work out of Lightroom unless I want a certain look. I do, however like the new upgrades with Lightroom 2.0  beta. I think if they waited every 2 or 2/12 years with an upgrade they would have more time to get more features in and the release would seem worth the upgrade. I definitely wouldn&#039;t trade my car in every 18 months. Just my opinion</description>
		<content:encoded><![CDATA[<p>Well I personally think Adobe is doing just fine and should hold out longer than 18 months for a new release. I just upgraded to CS3 about a month and a half ago. I waited because I wanted to make sure there weren&#8217;t any bugs like Apple did with Leopard or Canon did with the Mark III. Now I feel like I really didn&#8217;t need the upgrade because I hardly use any of the new features and I mostly work out of Lightroom unless I want a certain look. I do, however like the new upgrades with Lightroom 2.0  beta. I think if they waited every 2 or 2/12 years with an upgrade they would have more time to get more features in and the release would seem worth the upgrade. I definitely wouldn&#8217;t trade my car in every 18 months. Just my opinion</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jean-Luc</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-62022</link>
		<dc:creator>Jean-Luc</dc:creator>
		<pubDate>Fri, 30 May 2008 19:12:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-62022</guid>
		<description>I work as a developer for a big financial software company and I use LR. Dealing with users is not easy, especially when there are millions of them. We have to develop software for the masses, i.e., satisfy the vast majority of them because they have common requirements and needs. Then we develop to solve the problems for the rest of them... when we have time. We conduct a lot of usability lab sessions with actual customers to find out what they want, and the way they react in front of the software we give them (beta versions). We sit down in our darkrooms, behind our one way mirrors, eating m&amp;ms while the customer is trying to execute their every day tasks in our software. We film them, record what they say, record their eyes movements and correlate that to the item they look on their screen. This is extremely useful for us because the way developers think is different from the way users think (the plane analogy with tiny buttons and screens instead of knobs is accurate). It sounds like Adobe listens to their customers. Hopefully some day, there will be in LR or Bridge the features we (i.e., the vast majority of us) want. Hopefully, they will fix the bugs too and correct some inconsistencies between the 2 softwares.</description>
		<content:encoded><![CDATA[<p>I work as a developer for a big financial software company and I use LR. Dealing with users is not easy, especially when there are millions of them. We have to develop software for the masses, i.e., satisfy the vast majority of them because they have common requirements and needs. Then we develop to solve the problems for the rest of them&#8230; when we have time. We conduct a lot of usability lab sessions with actual customers to find out what they want, and the way they react in front of the software we give them (beta versions). We sit down in our darkrooms, behind our one way mirrors, eating m&amp;ms while the customer is trying to execute their every day tasks in our software. We film them, record what they say, record their eyes movements and correlate that to the item they look on their screen. This is extremely useful for us because the way developers think is different from the way users think (the plane analogy with tiny buttons and screens instead of knobs is accurate). It sounds like Adobe listens to their customers. Hopefully some day, there will be in LR or Bridge the features we (i.e., the vast majority of us) want. Hopefully, they will fix the bugs too and correct some inconsistencies between the 2 softwares.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bobby Orr</title>
		<link>http://www.scottkelby.com/blog/2008/archives/1422/comment-page-1#comment-61991</link>
		<dc:creator>Bobby Orr</dc:creator>
		<pubDate>Fri, 30 May 2008 17:10:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottkelby.com/blog/2008/archives/1422#comment-61991</guid>
		<description>As has been stated, the analogy just doesn&#039;t work because this isn&#039;t a menu where each patron can order separately.  This is one dish that has to satisfy everyone who came to the restaurant.  This is a popular restaurant too, frequented by a growing and more diverse group.  You have engineers, video producers, web designers, photographers, digital painters, beginners, advanced users... Every one of these groups has their own way of using Photoshop and their own ideas of what would take it to the next level.  Many of those ideas will contradict each other.  Supporting such an eclectic group is the problem that comes with bringing such a powerful and popular tool to the table.

From my experience in the software industry, one of the major hurdles with development is that creativity is stifled by the product life-cycle and marketability.  You have the guys that know the product inside and out and have a good idea of where they would like to take it to push it to that next level, then you have the company as a whole involving the marketing and research department that are asking questions like &quot;What is the most profitable sweet spot for a product life-cycle?&quot; or &quot;What new feature has that zing to it that will make the most people drool?&quot;.  The answer that first question can often hinder the creativity of the product engineers because they are given pretty extreme deadlines that automatically derail a lot of their ideas.  The answer to the second question begins an even more vicious cycle: new features are more marketable to Joe Public than fixing or fleshing out old ones-&gt;trying to compromise on time spent developing between new feature and fixing old ones-&gt;&quot;tacked on&quot; new features, little improvement to old ones-&gt;More features that will need to be fleshed out after release while competing with whatever needs to be tacked on to add &quot;zing&quot; to the next release.  Many companies are in a vicious cycle with branded titles because that sweet spot for profitable profit life cycle is 1 to 1 1/2 years.  

Photoshop actually gets the big dev team because that&#039;s the flagship of Adobe.  Consider many of their other titles that get pretty minimalist upgrades between versions because their dev teams are much smaller.  I&#039;m not just saying this life-cycle is applicable to Adobe only.  In fact, I would say that they are one of the better companies at handling it.  I&#039;m just trying to give a glimpse of the pain that most developers go through from a distant view of the company as a whole.

It has been stated in these comments that Adobe&#039;s shortcomings are what keep you in business, but I would think that is a bit of a cynical view.  Their shortcomings helped to drive a need for a lot of what is going on at Photoshopuser, but what is here has grown and thrived beyond the satisfying of that need thanks to your vision and hard work.</description>
		<content:encoded><![CDATA[<p>As has been stated, the analogy just doesn&#8217;t work because this isn&#8217;t a menu where each patron can order separately.  This is one dish that has to satisfy everyone who came to the restaurant.  This is a popular restaurant too, frequented by a growing and more diverse group.  You have engineers, video producers, web designers, photographers, digital painters, beginners, advanced users&#8230; Every one of these groups has their own way of using Photoshop and their own ideas of what would take it to the next level.  Many of those ideas will contradict each other.  Supporting such an eclectic group is the problem that comes with bringing such a powerful and popular tool to the table.</p>
<p>From my experience in the software industry, one of the major hurdles with development is that creativity is stifled by the product life-cycle and marketability.  You have the guys that know the product inside and out and have a good idea of where they would like to take it to push it to that next level, then you have the company as a whole involving the marketing and research department that are asking questions like &#8220;What is the most profitable sweet spot for a product life-cycle?&#8221; or &#8220;What new feature has that zing to it that will make the most people drool?&#8221;.  The answer that first question can often hinder the creativity of the product engineers because they are given pretty extreme deadlines that automatically derail a lot of their ideas.  The answer to the second question begins an even more vicious cycle: new features are more marketable to Joe Public than fixing or fleshing out old ones-&gt;trying to compromise on time spent developing between new feature and fixing old ones-&gt;&#8221;tacked on&#8221; new features, little improvement to old ones-&gt;More features that will need to be fleshed out after release while competing with whatever needs to be tacked on to add &#8220;zing&#8221; to the next release.  Many companies are in a vicious cycle with branded titles because that sweet spot for profitable profit life cycle is 1 to 1 1/2 years.  </p>
<p>Photoshop actually gets the big dev team because that&#8217;s the flagship of Adobe.  Consider many of their other titles that get pretty minimalist upgrades between versions because their dev teams are much smaller.  I&#8217;m not just saying this life-cycle is applicable to Adobe only.  In fact, I would say that they are one of the better companies at handling it.  I&#8217;m just trying to give a glimpse of the pain that most developers go through from a distant view of the company as a whole.</p>
<p>It has been stated in these comments that Adobe&#8217;s shortcomings are what keep you in business, but I would think that is a bit of a cynical view.  Their shortcomings helped to drive a need for a lot of what is going on at Photoshopuser, but what is here has grown and thrived beyond the satisfying of that need thanks to your vision and hard work.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
