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

Scaling Software Development: Teams & Codebase

Scaling Software Development: Teams & Codebase

Setup your environment, write code, commit, push and deploy, simple like that. When you are working alone, on a small project. When the development team and the codebase start to grow, things need to change.
This talk is about the challenges of scaling software development, multiplying team size and system complexity, and some strategies to deal with them. Including but not limited to: team sizes, code organization, quality assurance and automation.

This talk was a presented at the following events:
- Women Who Code Manila Tech Summit 2018
- Women Who Code CONNECT SF 2019

422cbb341dcd9a5dc4c7ac5350ca1009?s=128

Tutti Quintella

November 24, 2018
Tweet

More Decks by Tutti Quintella

Other Decks in Programming

Transcript

  1. Scaling Software Development Teams & Codebase

  2. Who am I? • Tutti Quintella (@tuttiq) • From São

    Paulo, Brazil • Computer Engineering major • Software Engineer since 2011
  3. DEAR WOMEN, WE NEED YOU HAVE PIZZA!

  4. MERCARI, THE SELLING APP!

  5. My trajectory • From Brazil, to London, to Tokyo •

    From 15-people startups to multinational companies with more than 400,000 employees • Teams from 3 to 13 members • From a simple web page to complex multi-app platforms • Software for 6, 300, 5000 or millions of users
  6. Disclaimer • This presentation touches controversial topics like: ◦ Team

    structures ◦ Development process ◦ Code readability ◦ Design patterns / "best practices" • A lot of the content is opinion based and subjective to exceptions / counter-arguments
  7. GET THE SLIDES • This presentation touches controversial topics like:

    ◦ Team structures ◦ Development process ◦ Code readability ◦ Design patterns / "best practices" • A lot of the content is opinion based and subjective to exceptions / counter-arguments
  8. Working in a software project 1. Write code 2. Commit

    changes and push to your repository 3. Deploy 4. It's live! Icons made by Freepik from www.flaticon.com
  9. Let's add some complexity

  10. Let's add some complexity Me

  11. Let's add some complexity Me Maria

  12. Scaling the problem... Conflict Inconsistency Redundancy ? ? ? ?

    Bug Rachel Joey Monica Ross Phoebe Chandler Me
  13. Problem snowball • Unstable system • Complexity keeps increasing •

    High stress, low productivity • Technical debt building up • Long time to ramp up new developers
  14. How to scale efficiently? • Reducing knowledge sharing bottleneck ◦

    Organized and intuitive codebase ◦ Documentation • Quality assurance • Automation of repetitive tasks • Structured teams & processes
  15. How to scale efficiently? • Reducing knowledge sharing bottleneck ◦

    Organized and intuitive codebase ◦ Documentation • Quality assurance • Automation of repetitive tasks • Structured teams & processes
  16. Scaling the codebase • System design • Coding style guide

    • Best practices Image copyright by HBO - Silicon Valley
  17. Scaling the codebase • System design • Coding style guide

    • Best practices
  18. System design: Design patterns • Splitting the code into smaller

    parts • More defined responsibilities • Well known patterns: easier to find people that already know them, or easier to find learning resources
  19. System design: Design patterns - MVC Image copyright by Sandro

    Mancuso at Codurance
  20. Sometimes only M, V and C is not enough... •

    Fat Controllers • Fat Models • Too much logic in one place
  21. System design: Problems of fat components • Harder to find

    logic when looking at the file structure • Harder to read and understand what a component does • Components are too specific and less reusable • Harder to break the app in separate modules • Harder to unit test
  22. System design: First advice "Skinny controllers, fat models" Result: Skinny

    controller, OBESE models. User.rb - 700+ lines...
  23. System design: Second advice • Mixins: pulling logic out of

    a component into a module/interface • Does it really organize your code?
  24. System design: Ways to extract logic • Mixins (properly implemented)

    • Value objects • Service objects • Policy objects • Form objects • Query objects
  25. System design: Ways to extract logic • Mixins (properly implemented)

    • Value objects • Service objects • Policy objects • Form objects • Query objects Refactoring Fat Components
  26. System design: Architecture microservices.io

  27. Scaling the codebase: Code organization • System design • Coding

    style guide • Best practices
  28. Coding style guide: Why? • Inconsistencies in the code format

    make development inefficient: ◦ Am I supposed to include className or class_name? ◦ Is sampleNumber a variable or a constant? ◦ Is this code inside this method/class/block or is it just an indentation inconsistency?
  29. Code organization: Style Guide Indent by 2 spaces at a

    time. (Google HTML/CSS Style Guide)
  30. Code organization: Style Guide Avoid single line methods. (The Ruby

    Style Guide)
  31. Scaling the codebase: Code organization • Design patterns • Coding

    style guide • Best practices
  32. Best practices: Single Responsibility Principle A class / method /

    component should have only one responsibility
  33. Best practices: DRY - Don't Repeat Yourself If you are

    copying and pasting the same thing with little alteration, it could probably be a reusable function / module / plugin...
  34. Code organization: Best practices Many others…. • The Boy Scout

    Rule • Avoid premature optimization • KISS - Keep It Simple Stupid
  35. How to scale efficiently? • Reducing knowledge sharing bottleneck ◦

    Organized and intuitive codebase ◦ Documentation • Structured teams & processes • Quality assurance • Automation of repetitive tasks
  36. Documentation: Code Annotation

  37. Documentation: Code Annotation

  38. Documentation: Code annotation to Wiki-style

  39. Documentation: Human-made Wiki

  40. How to scale efficiently? • Reducing knowledge sharing bottleneck ◦

    Organized and intuitive codebase ◦ Documentation • Quality assurance • Automation of repetitive tasks • Structured teams & processes
  41. Quality Assurance: Tests • Unit / integration tests ◦ Confidence

    in making changes without breaking working code My big refactor
  42. Quality Assurance: Monitoring • Monitoring real-time problems Image from Newrelic.com

  43. How to scale efficiently? • Reducing knowledge sharing bottleneck ◦

    Organized and intuitive codebase ◦ Documentation • Quality assurance • Automation of repetitive tasks • Structured teams & processes
  44. Automation: CI / CD • Continuous Integration • Continuous Delivery

    https://jenkins.io/artwork/
  45. Automation: Code review • Linters, safety checkers, etc

  46. How to scale efficiently? • Reducing knowledge sharing bottleneck ◦

    Organized and intuitive codebase ◦ Documentation • Quality assurance • Automation of repetitive tasks • Structured teams & processes
  47. Teams & processes: Problems • Everyone touching the same codebase

    • Everyone discussing the same domain • Everyone working across all technologies and business logic • Lack of boundaries & roles ⇒ big mess
  48. Teams & processes: Teams structure • Teams with more than

    5~6 people tend to organically split into smaller groups ◦ Insecurities about sharing things with everyone ◦ Too much context from too many sides, it's hard to absorb
  49. Teams & processes: Teams structure • Meetings with more than

    5~6 people tend to have a max of 2-3 active participants ◦ Insecurity about speaking to everyone ◦ Hard to find a break to jump in the conversation ◦ Takes longer to reach any conclusion ◦ Redundancy of opinions
  50. Teams & processes: Roles and Rules • Processes and standards

    that everyone follows ◦ PR / Ticket / Docs workflow and templates ◦ Project / Sprint cycle • Defined roles and tasks that everyone should do ◦ Code cleanup? Code review? Releases? • Task assignment strategy ◦ Self-assigned or manager assigned?
  51. Teams & Processes: Teams structures • Ways of structuring teams

    Project A Project B Business domain A Business domain B
  52. Teams & Processes: Teams structures • Ways of structuring teams

    Project A Project B Service A Service B
  53. Teams & Processes: Information sharing

  54. Last but not least • Knowledge sharing • Teamwork feeling

    • Communication
  55. How to scale efficiently • Reducing knowledge sharing bottleneck ◦

    Organized and intuitive codebase ◦ Documentation • Quality assurance • Automation of repetitive tasks • Structured teams & processes ✔ ✔ ✔ ✔ ✔ ✔
  56. THANK YOU Contact: • Email: tutti@womenwhocode.com • Facebook: https://fb.me/tuttiquintella •

    Twitter / Github: @tuttiq • LinkedIn: https://linkedin.com/in/tuttiq