<?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: Best of Comments</title>
	<atom:link href="http://thetoolsmiths.org/2009/02/02/best-of-comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://thetoolsmiths.org/2009/02/02/best-of-comments/</link>
	<description></description>
	<lastBuildDate>Mon, 16 Aug 2010 17:08:37 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Nick Darnell</title>
		<link>http://thetoolsmiths.org/2009/02/02/best-of-comments/comment-page-1/#comment-344</link>
		<dc:creator>Nick Darnell</dc:creator>
		<pubDate>Tue, 03 Feb 2009 05:05:34 +0000</pubDate>
		<guid isPermaLink="false">http://toolssig.wordpress.com/?p=36#comment-344</guid>
		<description>Dogfooding really is the key to making -anything- good.

Also, from my experience the closer your tools team sits to the users, the more likely they will get feedback.  We programmers are fairly sedentary creatures and if your tools developers are within earshot distance, the more likely they will be called over when something breaks or to hear valuable piece of feedback that just wont be captured by a bug report or a feature request.

I would add one more to the list though after reading it,

#8 Lack of Information Capture

Users should have a dead simple way of sending feedback to the tools developers.  If your group has a no/bad/complicated bug tracking system the less likely the developers will ever get the feedback they need because the user would rather live with an annoyance than deal with another bad tool.

The more quantifiable information you can gather from a users uses of your tool, the easier you can make it for them to improve the things they use the most.  Users can get in the habit of doing things in a way &#039;that works&#039; but isn&#039;t necessarily the best/most efficient way to accomplish a task.

Automated crash reporting.  Sure, your tool may dump some logs and other various files about what happened, but the users submitting the bug reports wont know to attach them or they may forget.  If your tool crashes, have it report the crash directly to the tools team and cut out the middle man.</description>
		<content:encoded><![CDATA[<p>Dogfooding really is the key to making -anything- good.</p>
<p>Also, from my experience the closer your tools team sits to the users, the more likely they will get feedback.  We programmers are fairly sedentary creatures and if your tools developers are within earshot distance, the more likely they will be called over when something breaks or to hear valuable piece of feedback that just wont be captured by a bug report or a feature request.</p>
<p>I would add one more to the list though after reading it,</p>
<p>#8 Lack of Information Capture</p>
<p>Users should have a dead simple way of sending feedback to the tools developers.  If your group has a no/bad/complicated bug tracking system the less likely the developers will ever get the feedback they need because the user would rather live with an annoyance than deal with another bad tool.</p>
<p>The more quantifiable information you can gather from a users uses of your tool, the easier you can make it for them to improve the things they use the most.  Users can get in the habit of doing things in a way &#8216;that works&#8217; but isn&#8217;t necessarily the best/most efficient way to accomplish a task.</p>
<p>Automated crash reporting.  Sure, your tool may dump some logs and other various files about what happened, but the users submitting the bug reports wont know to attach them or they may forget.  If your tool crashes, have it report the crash directly to the tools team and cut out the middle man.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: snk_kid</title>
		<link>http://thetoolsmiths.org/2009/02/02/best-of-comments/comment-page-1/#comment-343</link>
		<dc:creator>snk_kid</dc:creator>
		<pubDate>Tue, 03 Feb 2009 01:34:14 +0000</pubDate>
		<guid isPermaLink="false">http://toolssig.wordpress.com/?p=36#comment-343</guid>
		<description>Just wanted to comment on my comment before I give the wrong ideas,

first of all I might be wrong for some Boost components (disregarding any potential efficiency issues and/or longer build times), some maybe trivial to port to consoles. It all depends on the C++ ISO standard compliance of the compiler you&#039;re using (and it needs to be quite high) and resolving any platform dependent/specific components. I&#039;m only aware of 2 C++ compilers for the PS3, one is GCC and the other is the SNC compiler. If the GCC PS3 port is based on a relatively new version of GCC then you will mostly likely have very little issues building boost, maybe none even.

I know very little about SNC compiler but I just checked the SNC website and it basically says that the SNC compiler has enough C++ ISO standard compliance to support Boost.

Secondly, none of this should put any PC developers, hobbyists, or tool-smiths off from using Boost, it&#039;s a great addition to the C++ libraries which makes you productive and makes coding in C++ a little less painful (compared to other programming languages). We&#039;ve used boost for tools dev. You never know, when all the C++ compilers catch up with C++0x you might end up using a component that was heavily influenced from Boost.</description>
		<content:encoded><![CDATA[<p>Just wanted to comment on my comment before I give the wrong ideas,</p>
<p>first of all I might be wrong for some Boost components (disregarding any potential efficiency issues and/or longer build times), some maybe trivial to port to consoles. It all depends on the C++ ISO standard compliance of the compiler you&#8217;re using (and it needs to be quite high) and resolving any platform dependent/specific components. I&#8217;m only aware of 2 C++ compilers for the PS3, one is GCC and the other is the SNC compiler. If the GCC PS3 port is based on a relatively new version of GCC then you will mostly likely have very little issues building boost, maybe none even.</p>
<p>I know very little about SNC compiler but I just checked the SNC website and it basically says that the SNC compiler has enough C++ ISO standard compliance to support Boost.</p>
<p>Secondly, none of this should put any PC developers, hobbyists, or tool-smiths off from using Boost, it&#8217;s a great addition to the C++ libraries which makes you productive and makes coding in C++ a little less painful (compared to other programming languages). We&#8217;ve used boost for tools dev. You never know, when all the C++ compilers catch up with C++0x you might end up using a component that was heavily influenced from Boost.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jay</title>
		<link>http://thetoolsmiths.org/2009/02/02/best-of-comments/comment-page-1/#comment-342</link>
		<dc:creator>Jay</dc:creator>
		<pubDate>Mon, 02 Feb 2009 23:33:52 +0000</pubDate>
		<guid isPermaLink="false">http://toolssig.wordpress.com/?p=36#comment-342</guid>
		<description>&gt; 7. Not enough dogfooding
Often, the people who develop the tools don’t actually use them. This can lead to a number of problems, including an overly complex interface and a host of usability issues.

I have been there... this is absolutely awful when you are given a tool with little or no documentation. You don&#039;t know how it works and the people who wrote it are nowhere to be seen...</description>
		<content:encoded><![CDATA[<p>&gt; 7. Not enough dogfooding<br />
Often, the people who develop the tools don’t actually use them. This can lead to a number of problems, including an overly complex interface and a host of usability issues.</p>
<p>I have been there&#8230; this is absolutely awful when you are given a tool with little or no documentation. You don&#8217;t know how it works and the people who wrote it are nowhere to be seen&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Geoff Evans</title>
		<link>http://thetoolsmiths.org/2009/02/02/best-of-comments/comment-page-1/#comment-341</link>
		<dc:creator>Geoff Evans</dc:creator>
		<pubDate>Mon, 02 Feb 2009 18:38:50 +0000</pubDate>
		<guid isPermaLink="false">http://toolssig.wordpress.com/?p=36#comment-341</guid>
		<description>&gt; 7. Not enough dogfooding
Often, the people who develop the tools don’t actually use them. This can lead to a number of problems, including an overly complex interface and a host of usability issues.

Agree 100%.  I am currently trying to combat this problem at Insomniac.</description>
		<content:encoded><![CDATA[<p>&gt; 7. Not enough dogfooding<br />
Often, the people who develop the tools don’t actually use them. This can lead to a number of problems, including an overly complex interface and a host of usability issues.</p>
<p>Agree 100%.  I am currently trying to combat this problem at Insomniac.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
