Comments on: Software Product Delivery – 20 Rules? http://tynerblain.com/blog/2006/12/07/software-product-delivery-rules/ Software product success. Thu, 18 Mar 2010 20:39:50 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Scott Sehlhorst http://tynerblain.com/blog/2006/12/07/software-product-delivery-rules/comment-page-1/#comment-58312 Scott Sehlhorst Sun, 10 Dec 2006 23:35:16 +0000 http://tynerblain.com/blog/2006/12/07/software-product-delivery-rules/#comment-58312 Hey Deepak, I would definitely have issues with measurable "extra time" to go back and document code. Documenting as you go, however, doesn't really add time - or at least did not in my experiences as a developer, or when I was managing other developers. Rishikesh, thanks for the original article, and for the comments here - hope you'll stick around. Your clarification on #11 helps a lot, thanks! Hey Deepak, I would definitely have issues with measurable “extra time” to go back and document code. Documenting as you go, however, doesn’t really add time – or at least did not in my experiences as a developer, or when I was managing other developers.

Rishikesh, thanks for the original article, and for the comments here – hope you’ll stick around. Your clarification on #11 helps a lot, thanks!

]]> By: Deepak http://tynerblain.com/blog/2006/12/07/software-product-delivery-rules/comment-page-1/#comment-58247 Deepak Sun, 10 Dec 2006 02:37:11 +0000 http://tynerblain.com/blog/2006/12/07/software-product-delivery-rules/#comment-58247 I am a little more inclined to agree with Rishikesh on the part about software code documentation. The one thing that always frustrated me as a product manager was the extra time those added to our delivery schedules. I am sure there is a happy medium between too much documentation and the "code is documentation" camps. I completely agree on #8. Best way to minimize risk. I am a little more inclined to agree with Rishikesh on the part about software code documentation. The one thing that always frustrated me as a product manager was the extra time those added to our delivery schedules. I am sure there is a happy medium between too much documentation and the “code is documentation” camps.

I completely agree on #8. Best way to minimize risk.

]]> By: Rishikesh Tembe http://tynerblain.com/blog/2006/12/07/software-product-delivery-rules/comment-page-1/#comment-58210 Rishikesh Tembe Sat, 09 Dec 2006 17:56:48 +0000 http://tynerblain.com/blog/2006/12/07/software-product-delivery-rules/#comment-58210 Great post! I just wanted to clarify a few points: Regarding point #11, I'm not suggesting that clients' deadlines and constraints are not important. On the other hand, I've seen too many engineering teams perform heroics to meet the project deadlines, often when it would have been OK from the client's perspective if the deadline had slipped by a week or a month. In retrospect, I'm going to clarify in my post that one should always keep the lines of communication open with the customers. About #13 and #14, I agree that absolutes are not always feasible especially in the software industry. However, if we try to build these absolutes (documentation, code readibility etc.) into our processes, then most times they should not impact release dates or other potentially higher priority factors. Its more of a long term goal that we should try to achieve without impacting our short term commitments. Great post! I just wanted to clarify a few points:

Regarding point #11, I’m not suggesting that clients’ deadlines and constraints are not important. On the other hand, I’ve seen too many engineering teams perform heroics to meet the project deadlines, often when it would have been OK from the client’s perspective if the deadline had slipped by a week or a month.
In retrospect, I’m going to clarify in my post that one should always keep the lines of communication open with the customers.

About #13 and #14, I agree that absolutes are not always feasible especially in the software industry. However, if we try to build these absolutes (documentation, code readibility etc.) into our processes, then most times they should not impact release dates or other potentially higher priority factors. Its more of a long term goal that we should try to achieve without impacting our short term commitments.

]]> By: James Taylor http://tynerblain.com/blog/2006/12/07/software-product-delivery-rules/comment-page-1/#comment-58149 James Taylor Fri, 08 Dec 2006 19:23:01 +0000 http://tynerblain.com/blog/2006/12/07/software-product-delivery-rules/#comment-58149 I like the list also but I think number 1 and number 14 need some edits. Check out http://www.edmblog.com/weblog/2006/12/using_business_.html to see what I mean. I like the list also but I think number 1 and number 14 need some edits. Check out http://www.edmblog.com/weblog/2006/12/using_business_.html to see what I mean.

]]>