Comments on: How to develop software like commanding a tank http://gojko.net/2006/10/11/how-to-develop-software-like-commanding-a-tank/ Building software that matters Tue, 15 May 2012 10:05:44 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Agustin Villena http://gojko.net/2006/10/11/how-to-develop-software-like-commanding-a-tank/comment-page-1/#comment-14 Agustin Villena Sat, 14 Oct 2006 01:36:22 +0000 http://gojko.net/2006/10/11/how-to-develop-software-like-commanding-a-tank/#comment-14 To all interested in this article, Mary and Tom Poppendieck explores this subject in their book "Lean Software Management", proposing 7 simple rules to follow when unexpected things happens in a software project: - Eliminate Waste - Build Quality In - Create Knowledge - Defer Commitment - Deliver Fast - Respect People - Optimize the Whole To all interested in this article, Mary and Tom Poppendieck explores this subject in their book “Lean Software Management”, proposing 7 simple rules to follow when unexpected things happens in a software project:
- Eliminate Waste
- Build Quality In
- Create Knowledge
- Defer Commitment
- Deliver Fast
- Respect People
- Optimize the Whole

]]> By: John K http://gojko.net/2006/10/11/how-to-develop-software-like-commanding-a-tank/comment-page-1/#comment-13 John K Wed, 11 Oct 2006 14:50:54 +0000 http://gojko.net/2006/10/11/how-to-develop-software-like-commanding-a-tank/#comment-13 Great bullet point list. The contextual information and the list you provide makes for an interesting read and a well done review of the book. I suspect that there is another benefit to consistently taking this approach. I'm thinking of your junior and intermediate developers. I know that I've learned a lot from watching people who consistently make good, thoughtful, sometime even truly great decisions. There's nothing like learning by seeing something in action. Chances are high that the beginning and intermediate developers will learn from you and will either knowingly or unknowingly incorporate this approach into how they work, how they ask questions etc. I know this is true because I've seen many junior developers pick up terrible habits from their managers or leadership (think, let's just code this any way we can and get the product out as quickly as we can and worry about our framework, codebase, whatever later on). thanks for this post! Great bullet point list. The contextual information and the list you provide makes for an interesting read and a well done review of the book.

I suspect that there is another benefit to consistently taking this approach. I’m thinking of your junior and intermediate developers.

I know that I’ve learned a lot from watching people who consistently make good, thoughtful, sometime even truly great decisions. There’s nothing like learning by seeing something in action. Chances are high that the beginning and intermediate developers will learn from you and will either knowingly or unknowingly incorporate this approach into how they work, how they ask questions etc. I know this is true because I’ve seen many junior developers pick up terrible habits from their managers or leadership (think, let’s just code this any way we can and get the product out as quickly as we can and worry about our framework, codebase, whatever later on).

thanks for this post!

]]>