Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Failing Fast in Startup Programming

Failing Fast in Startup Programming

Guest lecture presented at the 'startup programming' course at the University of Victoria, BC, Canada, September 2014.

https://github.com/alexeyza/startup-programming

Arie van Deursen

September 26, 2014
Tweet

More Decks by Arie van Deursen

Other Decks in Programming

Transcript

  1. My  Background   •  Professor  in  SoHware  Engineering,   DelH

     University  of  Technology  (2003  -­‐  …)   •  Technical  Due  Diligence  (contracRng)   P3  Technology  Partners  (1999-­‐2001)   •  Co-­‐founder  (2000)   SoHware  Improvement  Group   •  Co-­‐founder  (2010)  Infotron   •  Board  member  (2013  -­‐  …),  OrangeTribes  
  2. Startup?  Why!?     “There  are  people   who  are

     crazy   enough  to  think  they   can  change  the   world.”   4   Apple  -­‐  Here's  to  the  Crazy  Ones  (1997)   h^ps://flic.kr/p/bCGX1E,  johanneshjensen  
  3. Startup  Chaos:  So  Much  To  Do   •  Programming  

    •  TesRng   •  Sales   •  Product  development   •  UX  Design   •  Hiring  and  Firing   •  Investors   •  Finances   •  Deployment   •  Infrastructure   •  MarkeRng   •  Office  space   •  CompeRRon   •  Pricing   •  Customers   …  and  there  is  just  the     three  of  you.  
  4. …  we  have  come  to  value:   Individuals  and  

    interacRons     Working  soHware     Customer   collaboraRon     Responding  to  change   Processes  and     tools     Comprehensive   documentaRon     Contract  negoRaRon     Following  the  plan   12   over   While  there  is  value  in  the  items  on  the  right,     we  value  the  items  on  the  le@  more.  
  5. Scrum  Lifecycle   30  days   24  hours   Product

     Backlog   As  prioriRzed  by  Product  Owner   Sprint  Backlog   Backlog  tasks   expanded   by  team   PotenRally  Shippable   Product  Increment   Daily  Scrum   MeeRng   13  
  6. ConRnuous  Delivery   •  “Any  commit  to  master  is  a

     working  version”   •  To  demo  to  customers,  investors,  …   •  To  get  feedback   •  To  see  progress   •  To  fail  fast.  
  7. Test  AutomaRon     “Design  of  a  so@ware  system  

      that  exercises  another  system     with  the  intent  of  finding  bugs”     ResulRng  automated  test  suite  can  be     executed  with  a  click  of  a  bu^on,   or  upon  any  commit  to  master    
  8. 16   Unit  TesRng  with  JUnit   •  Write  and

     invoke  tests  in  Java   •  AutomaRcally  verify  results  in  Java   •  Organize  tests  into  suites   •  Uniform  test  case  representaRon   •  Light-­‐weight  &  easy  to  learn   •  Typical  process  used:       – “Test-­‐Driven  (test-­‐first)  development”   Beck  &  Gamma,  “Test  Infected”  
  9. Acceptance  Tests  from  User  Stories   Title (one line describing

    the story) Narrative: As a [role] I want [feature] So that [benefit] Acceptance Criteria: (presented as Scenarios) Scenario 1: Title Given [context] And [some more context]... When [event] Then [outcome] And [another outcome]... Scenario 2: ...   Outside-­‐in   •  Business-­‐outcomes   •  Feature  set     Feature  captured  as  story:   •  Scope   •  Acceptance  criteria   20   h^p://dannorth.net/whats-­‐in-­‐a-­‐story/  
  10. Story: Account Holder withdraws cash As an Account Holder I

    want to withdraw cash from an ATM So that I can get money when the bank is closed Scenario 1: Account has sufficient funds Given the account balance is $100 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should dispense $20 And the account balance should be $80 And the card should be returned 21  
  11. Feedback  in  Test-­‐Driven  Development   Write  a     FAILING

      Unit  test   Make  the     test  pass   25  
  12. Feedback  in  Test-­‐Driven  Development   Write  a     FAILING

      Unit  test   Make  the     test  pass   Refactor   26  
  13. Feedback  in  Test-­‐Driven  Development   Write  a     FAILING

      Unit  test   Make  the     test  pass   Refactor   Write  a  failing   ACCEPTANCE   test   27  
  14. Some  TesRng  Advice   •  A  test  case  is  an

     executable  example   – Keep  it  simple!   •  Different  test  types  target  different  types  of   faults  –  they  address  different  fault  models   – (Many)  small  unit  tests  for  specific  behavior   – Fewer  but  larger  e2e  tests  purng  it  all  together   •  Invest  in  a  test  harness  /  infrastructure  
  15. Clean  Code?   •  Clean  up  your  code  and  refactor

      – “Do  the  simplest  thing  that  could  possibly  work”   •  Beware  of  over-­‐abstracRon:   – “You  Ain’t  Going  to  Need  It”  –  YAGNI!     •  Clean  coding  should  be  part  of  your  genes   – PracIce  clean  coding  whenever  you  can.  
  16. Technical  Debt    “Shipping  first  Ime  code  is  like  going

      into  debt.  A  liKle  debt  speeds  development     so  long  as  it  is  paid  back  promptly  with  a     rewrite…            The  danger  occurs  when  the  debt  is  not  repaid.  Every   minute  spent  on  not-­‐quite-­‐right  code  counts  as  interest   on  that  debt.       EnIre  engineering  organizaIons  can  be  brought  to  a   stand-­‐sIll  under  the  debt  load  of  an  unconsolidated   implementaIon,  object-­‐oriented  or  otherwise.”   33   Ward  Cunningham,  OOPSLA  1992  
  17. Summary   •  Fail  Fast;  Fail  OHen   •  Always

     have  a  working  version   •  Test  automaRon  is  your  friend   •  Find  right  balance  between  unit  and   end-­‐to-­‐end  test  suite