Comments on: When Good is Enough (and when it isn’t) http://littlesquare.com/2009/12/when-good-is-enough-and-when-it-isnt/ Just a little square in a sea of blogs Wed, 08 Feb 2012 14:58:58 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: ajordens http://littlesquare.com/2009/12/when-good-is-enough-and-when-it-isnt/#comment-171 ajordens Thu, 24 Dec 2009 18:27:30 +0000 http://littlesquare.com/2009/12/01/when-good-is-enough-and-when-it-isnt/#comment-171 Depends on your definition of 'well executed'. And who's to say that the 100% complete plan would be shippable either. Obviously one gets to 80% quicker than 100% and should be in a position to fail faster if it turns out it's a mistake. However, if you're executing effectively, you should know well in advance of a ship date if you're on the mark. Basically, what I'm suggesting is that the focus should be on getting less features out but with more frequency (but it's a difficult thing to do with enterprise software). As for a developer's role, IMO it should be to produce 'usable' code, adding value for both the customer and business. Usable code is shippable, not all shippable code is usable. Depends on your definition of ‘well executed’. And who’s to say that the 100% complete plan would be shippable either.

Obviously one gets to 80% quicker than 100% and should be in a position to fail faster if it turns out it’s a mistake. However, if you’re executing effectively, you should know well in advance of a ship date if you’re on the mark.

Basically, what I’m suggesting is that the focus should be on getting less features out but with more frequency (but it’s a difficult thing to do with enterprise software).

As for a developer’s role, IMO it should be to produce ‘usable’ code, adding value for both the customer and business. Usable code is shippable, not all shippable code is usable.

]]> By: Tim http://littlesquare.com/2009/12/when-good-is-enough-and-when-it-isnt/#comment-170 Tim Wed, 02 Dec 2009 08:09:09 +0000 http://littlesquare.com/2009/12/01/when-good-is-enough-and-when-it-isnt/#comment-170 I think your statement: "a well executed plan only 80% complete, is worth leaps and bounds more than a flawed plan 100% complete" is strange. The risk with something only 80% complete is if it's the *wrong* 80%, and now we cannot ship. I believe a software developer's role is to "produce shippable code". I think that you agree with me. :) I do *love* the mantra of "Get it in, because you need the feedback". It always amazes me how much discussion and debate and swirl can happen over vapour-ware. Just build a simple mock up that people can look at and interact with. Then you will find out what really matters. I think your statement: “a well executed plan only 80% complete, is worth leaps and bounds more than a flawed plan 100% complete” is strange.

The risk with something only 80% complete is if it’s the *wrong* 80%, and now we cannot ship.

I believe a software developer’s role is to “produce shippable code”. I think that you agree with me. :)

I do *love* the mantra of “Get it in, because you need the feedback”. It always amazes me how much discussion and debate and swirl can happen over vapour-ware. Just build a simple mock up that people can look at and interact with. Then you will find out what really matters.

]]>