Failing Fast in Startup Programming

Slide 1

Slide 1 text

Presented at the Startup Programming Course at University of Victoria, Sept 26, 2014

Slide 2

Slide 2 text

Jim Gray, Tandem Computer, 1985

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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://ﬂic.kr/p/bCGX1E, johanneshjensen

Slide 5

Slide 5 text

h^p://www.slideshare.net/missrogue/so-‐you-‐want-‐to-‐do-‐a-‐startup-‐eh

Slide 6

Slide 6 text

Startup Chaos: So Much To Do •  Programming •  TesRng •  Sales •  Product development •  UX Design •  Hiring and Firing •  Investors •  Finances •  Deployment •  Infrastructure •  MarkeRng •  Oﬃce space •  CompeRRon •  Pricing •  Customers … and there is just the three of you.

Slide 7

Slide 7 text

Common Species of Code h^p://www.willa.me/2013/11/the-‐six-‐most-‐common-‐species-‐of-‐code.html

Slide 8

Slide 8 text

h^p://www.willa.me/2013/11/the-‐six-‐most-‐common-‐species-‐of-‐code.html

Slide 9

Slide 9 text

h^p://www.willa.me/2013/11/the-‐six-‐most-‐common-‐species-‐of-‐code.html

Slide 10

Slide 10 text

h^p://www.willa.me/2013/11/the-‐six-‐most-‐common-‐species-‐of-‐code.html

Slide 11

Slide 11 text

h^p://www.willa.me/2013/11/the-‐six-‐most-‐common-‐species-‐of-‐code.html

Slide 12

Slide 12 text

… 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.

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

ConRnuous Delivery •  “Any commit to master is a working version” •  To demo to customers, investors, … •  To get feedback •  To see progress •  To fail fast.

Slide 15

Slide 15 text

Test AutomaRon “Design of a so@ware system that exercises another system with the intent of ﬁnding bugs” ResulRng automated test suite can be executed with a click of a bu^on, or upon any commit to master

Slide 16

Slide 16 text

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-‐ﬁrst) development” Beck & Gamma, “Test Infected”

Slide 17

Slide 17 text

End2End Tests with WebDriver

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

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/

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Feedback in Test-‐Driven Development Write a FAILING Unit test Make the test pass Refactor Write a failing ACCEPTANCE test 27

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

ConRnuous IntegraRon: Travis

Slide 30

Slide 30 text

ConRnuous IntegraRon: Jenkins

Slide 31

Slide 31 text

ConRnuous IntegraRon: Team City

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

Technical Debt “Shipping ﬁrst 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

Slide 34

Slide 34 text

Fowler’s Technical Debt Quadrant 34 Mar7n Fowler 2009, 2010

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Presented at the Startup Programming Course at University of Victoria, Sept 26, 2014