Thursday, November 17, 2011

Notes From Implementing Lean Software Development - From Concept to Cash

I read the Poppendieck's book on implementing lean software development almost a year ago and I continue to go back to it for advice and insight. I finally brought myself to put together a brief summary on the first half of the book and decided to share it with my blog readers. One of the great things about the book is the set of industry examples they provide to exemplify to the points that they are making. This is especially useful to me, since I often have no debating ammunition aside from my personal beliefs. To make it easy to look up those examples, I'm including the page numbers along with the ideas below.


The book can be purchased from Amazon



  • pg 24 Early specification does NOT reduce waste, it encourages it
  • pg 28 "Do It Right the First Time"
    • This means TEST first to keep bugs OUT. It does NOT mean think of all possible future needs of the feature.
  • pg 32 Forecast predictions, not fact. Avoid "analysis paralysis."
    • Build processes that allow quick feedback and responses, rather than building for an uncertain feature
  • pg 33 "Plans are useless, but planning is indispensable" - Eisenhower
  • pg 34 Achieving high value, low stress feature delivery is impossible WITHOUT superb quality (in the form of tests)
  • pg 38 Sub-optimizing is BAD
    • E.g. Optimizing the writing of ONLY the feature code, but NOT the test code
    • --result--> More complex code, higher potential for introducing new bugs, longer to write new code
    • E.g. Optimizing ONLY your part of the process. The overall process still drags along and you get frustrated.
    • --solution--> Team ownership!
  • pg 74 7 Wastes
    • Relearning by failing to engage current knowledge
    • --solution?--> Information needs to be accessible. People should not be siloed and should talk often.
  • pg 101 Increase estimation reliability by decreasing variability (i.e. estimate and commit to smaller projects)
  • pg 105 FASTER delivery --> Reduce the number of things in WIP (queue theory)
  • pg 124 Exec thinking is so ingrained that Lean concepts are invisible
  • pg 126 Group is NOT a team until everyone is COMMITTED
    • E.g. Sports - track versus rowing
  • pg 150 Story by Rally does a great job highlighting the DRAWBACKS of Technical DEBT incurred by NOT slowing down to address untested code
  • pg 151 You must *commit* to action items coming out of Retrospectives
    • Nothing is accomplished if you only discuss problems.
  • pg 153 More important than processes is LEARNING (understanding), SHARING, and SOLVING PROBLEMS
    • Experience over documentation. 
    • Refined documentation far outweighs garrulous documentation

Sunday, November 13, 2011

HTML5 Drag and Drop - Chrome Not Working?

The W3C standard defines seven event types for drag and drop, http://dev.w3.org/html5/spec/dnd.html#dndevents.  Pretty cool to have so many options, but the nieve reader may be surprised to learn how they work together. Specifically, for people binding to the "drop" event.

The default behavior of the dragover event is described as such, "Reset the current drag operation to 'none'". So what does this mean for developers binding to the drop event? It means, that unless you prevent the default behavior of dragover, your drop event will not fire. This is not a fun one to learn on your own.

Friday, November 11, 2011

Could not evaluate: Could not retrieve information from source(s)

Oops! I was evaluating a template, NOT a file.

file {
    "/destination/file/path":
          source => template("path/to/template");
}

The key is that "source" should be "content"!


file {
    "/destination/file/path":
          content => template("path/to/template");
}

So, what was happening behind the scenes is that puppet was trying to source the literal value of the evaluated template file. Could be useful?

Wednesday, November 9, 2011

Reading /etc/rc.status

What Cool Bash Stuff Did I Learn?
  • What does RC Stand For? ==> Resource Control
  • How do I tell vim my file type is Bash? 
    • I can set the following anywhere in the file,
      • # vim: set filetype=sh
      • # vim: syntax=sh
  • How can I make my if()s look prettier? ==> Use {}
    [ -e $pathToFile ] || {
       echo >&2 "File $file does not exit"
       exit 1
    }
    
  • How do I prompt a command to ask me for input?
    • ==> cat file-to-prepend - file-to-append > output-file