Comments on: The developer’s true goal http://lostechies.com/jimmybogard/2011/01/05/the-developer-s-true-goal/ Strong opinions, weakly held Sun, 19 May 2013 03:22:18 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: RichB http://lostechies.com/jimmybogard/2011/01/05/the-developer-s-true-goal/#comment-2757 RichB Fri, 07 Jan 2011 10:56:14 +0000 /blogs/jimmy_bogard/archive/2011/01/05/the-developer-s-true-goal.aspx#comment-2757 You've missed what I view as the best argument for writing less code - fewer bugs. You’ve missed what I view as the best argument for writing less code – fewer bugs.

]]> By: Steve http://lostechies.com/jimmybogard/2011/01/05/the-developer-s-true-goal/#comment-2756 Steve Wed, 05 Jan 2011 15:26:03 +0000 /blogs/jimmy_bogard/archive/2011/01/05/the-developer-s-true-goal.aspx#comment-2756 There haven't been many places where I've worked where the developer has final say over whether a features should be implemented or not. Actually, there has been only one, the startup where I was the CTO. Everywhere else, a developer might resist, or say something is stupid, but it's rarely his/her call on whether it needs to gets in or not. This leads to the bigger problem, in that once a feature has made it into a published version of your software, it's very difficult to pull it out. If only 5% of your customers utilize a features, removing it will cause them to freak, and your Sales/Marketing/PR people really won't care that other 95% of your customer base at the very least weren't impacted (and maybe even benefited) from it's removal. While I don't disagree with anything in your post for a theoretical stand point, in reality doing things like developing a minimum set of features before releasing into Production isn't always possible. There haven’t been many places where I’ve worked where the developer has final say over whether a features should be implemented or not. Actually, there has been only one, the startup where I was the CTO. Everywhere else, a developer might resist, or say something is stupid, but it’s rarely his/her call on whether it needs to gets in or not.

This leads to the bigger problem, in that once a feature has made it into a published version of your software, it’s very difficult to pull it out.

If only 5% of your customers utilize a features, removing it will cause them to freak, and your Sales/Marketing/PR people really won’t care that other 95% of your customer base at the very least weren’t impacted (and maybe even benefited) from it’s removal.

While I don’t disagree with anything in your post for a theoretical stand point, in reality doing things like developing a minimum set of features before releasing into Production isn’t always possible.

]]>