<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>t+1 - Latest Comments in My favorite software quality metric is the income statement</title><link>http://tplus1.disqus.com/</link><description></description><atom:link href="http://tplus1.disqus.com/my_favorite_software_quality_metric_is_the_income_statement/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Wed, 26 Jan 2011 07:15:07 -0000</lastBuildDate><item><title>Re: My favorite software quality metric is the income statement</title><link>http://blog.tplus1.com/index.php/2009/06/28/my-favorite-software-quality-metric-is-the-income-statement/#comment-134762249</link><description>&lt;p&gt;Happy to share your blog!&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">sante mutuelle</dc:creator><pubDate>Wed, 26 Jan 2011 07:15:07 -0000</pubDate></item><item><title>Re: My favorite software quality metric is the income statement</title><link>http://blog.tplus1.com/index.php/2009/06/28/my-favorite-software-quality-metric-is-the-income-statement/#comment-130527156</link><description>&lt;p&gt;Great resource!&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">rachat de credit</dc:creator><pubDate>Tue, 18 Jan 2011 08:38:21 -0000</pubDate></item><item><title>Re: My favorite software quality metric is the income statement</title><link>http://blog.tplus1.com/index.php/2009/06/28/my-favorite-software-quality-metric-is-the-income-statement/#comment-13764435</link><description>&lt;p&gt;Thanks for the comment!&lt;/p&gt;

&lt;p&gt;I see poor vision creeping in when landing the next deal takes on too much importance.  I understand why the sales guys rush into my office after every single demo and ask if I could bolt on half a dozen extraneous features.  They're just trying to land the deal.  I know that revenue really matters.&lt;/p&gt;

&lt;p&gt;But I spent our first year doing whatever our beta customers asked, and the app suffered for it. We had lots of unrelated screens, each with a different style, built for separate customers to do different things.  It was a mess.&lt;/p&gt;

&lt;p&gt;Now I'm trying to balance the need to get that hockey-stick revenue growth chart against the need to keep the app from turning into a big unholy mess begging to be put out of its misery.&lt;/p&gt;

&lt;p&gt;It's fun.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Matt Wilson</dc:creator><pubDate>Fri, 31 Jul 2009 20:00:19 -0000</pubDate></item><item><title>Re: My favorite software quality metric is the income statement</title><link>http://blog.tplus1.com/index.php/2009/06/28/my-favorite-software-quality-metric-is-the-income-statement/#comment-13753159</link><description>&lt;p&gt;I have often found that bad code is likely to happen when you have too many requirements and too little time or people to do it in.  Caring programmers, when given a fair amount of time, will write good code.&lt;/p&gt;

&lt;p&gt;Additionally, I have found that poor product vision also leads to less maintainable code.  Good programmers, when given a strong vision about where the product is going, will make good decisions about what can be safely "one-offed" and what requires more serious design effort.&lt;/p&gt;

&lt;p&gt;I guess what I'm trying to say is that poor vision and poor focus can lead to a poor code base just as surely as poor programmers.  Also, poor targeting of customers can also lead to poor code bases, as features are shoe-horned into a product whose vision gets blurrier and blurrier.&lt;/p&gt;

&lt;p&gt;So if you are looking at declining margins, ask yourself are we chasing after the right customers?  Do we have the right product vision?  Have we clearly defined the product vision and direction to our team?  Have we found all customers for our code/product as it exists today?&lt;/p&gt;

&lt;p&gt;I recently read a good article with this statement, which I think in a manner sums up looking at things the other way.&lt;/p&gt;

&lt;p&gt;"There are always more things to do than there is time to do them.  Startups are a continuous exercise in deciding what not to do.  You can sometimes win by just not doing things faster than your competition."&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">AceGopher</dc:creator><pubDate>Fri, 31 Jul 2009 15:22:09 -0000</pubDate></item></channel></rss>
