Coding for a Living vs Coding for a Mark

This talk was given to the first year students at the University of Surrey. The main objective was to introduce them to the culture of the tech industry, and the main principles of eXtreme Programming.
The talk was designed to serve as an industry report of a kind, drawing on real life examples of using XP practices both successfully, and not.

Transcript

1. Coding for a Living vs Coding for a Mark @irinatsyganok irina.tsyganok@net-a-porter.com
2. Background Test Automation User Experience Web Development Java Development
3. Agenda The culture. Agile Manifesto Working together. eXtreme Programming Building software the eXtreme Way Shipping to production XP at YNAP XP in the context of academia The ideal YNAP developer
4. The culture. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it.
5. The culture. Agile Manifesto Individuals and interactions over processes and tools
6. The culture. Agile Manifesto Working software over comprehensive documentation
7. The culture. Agile Manifesto Customer collaboration over contract negotiation
8. The culture. Agile Manifesto Responding to change over following a plan
9. Working together. eXtreme Programming [XP]
10. Working together. eXtreme Programming Adaptability over Predictability Lower the cost of change A mechanism for social change
11. Communication Respect Simplicity Courage Feedback Working together. Values of XP
12. Building software. XP Practices Planning Iterations iteration planning frequent, small releases “Without planning, we are individuals with haphazard connections and effectiveness. We are a team when we plan and work in harmony” - Kent Beck
13. Building software. XP Practices Managing Daily stand up Open working space Sustainable pace Move around Fix XP when it breaks “Follow XP rules to start with, but do not hesitate to change what does not work” - extremeprogramming.org
14. Building software. XP Practices “The hardest part of understanding and adopting XP is system metaphor”- Avraham Poupko, Architect Manager @Cisco Designing Simplicity System metaphor No functionality is added early Refactor, refactor, refactor
15. Building software. XP Practices Testing Unit Functional Acceptance Sanity Performance “There are two ways to write error-free programs; only the third works” - Alan J Perils
16. Building software. XP Practices “Well, let’s just code it up and see what happens. If it doesn’t work, we’ll change it” - Ward Cunningham Coding Customer is always available Write unit tests first Pair-program all production code Integrate often Use collective ownership
17. Shipping to production -  Release stand up -  Continuous Integration [CI] -  Continuous Deployment [CD] -  Small, frequent releases -  Performance monitoring and benchmarking
18. XP at NAP ‘In theory, theory and practice are the same. In practice, they are not’- Anonymous
19. XP at NAP Frequent, small releases Open space Sustainable pace Move around Pair-programming
20. XP at NAP Customer is always available Iteration planning Testing strategy Move around Pair-programming System metaphor
21. XP in the context of academia
22. The ideal YNAP developer Curious Embraces change Friendly Drives own development Collaborative Honest Polite Responsible Open-minded Proud
23. Final Thoughts. “To me, programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge” - Grace Hopper