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

Tutti Quintella

November 24, 2018
Tweet

More Decks by Tutti Quintella

Other Decks in Programming

Transcript

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

    Paulo, Brazil • Computer Engineering major • Software Engineer since 2011
  2. 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
  3. 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
  4. 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
  5. 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
  6. Scaling the problem... Conflict Inconsistency Redundancy ? ? ? ?

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

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

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

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

    • Best practices Image copyright by HBO - Silicon Valley
  11. 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
  12. Sometimes only M, V and C is not enough... •

    Fat Controllers • Fat Models • Too much logic in one place
  13. 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
  14. System design: First advice "Skinny controllers, fat models" Result: Skinny

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

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

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

    • Value objects • Service objects • Policy objects • Form objects • Query objects Refactoring Fat Components
  18. 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?
  19. Code organization: Style Guide Indent by 2 spaces at a

    time. (Google HTML/CSS Style Guide)
  20. Best practices: Single Responsibility Principle A class / method /

    component should have only one responsibility
  21. 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...
  22. Code organization: Best practices Many others…. • The Boy Scout

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

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

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

    in making changes without breaking working code My big refactor
  26. How to scale efficiently? • Reducing knowledge sharing bottleneck ◦

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

    Organized and intuitive codebase ◦ Documentation • Quality assurance • Automation of repetitive tasks • Structured teams & processes
  28. 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
  29. 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
  30. 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
  31. 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?
  32. Teams & Processes: Teams structures • Ways of structuring teams

    Project A Project B Business domain A Business domain B
  33. How to scale efficiently • Reducing knowledge sharing bottleneck ◦

    Organized and intuitive codebase ◦ Documentation • Quality assurance • Automation of repetitive tasks • Structured teams & processes ✔ ✔ ✔ ✔ ✔ ✔
  34. THANK YOU Contact: • Email: [email protected] • Facebook: https://fb.me/tuttiquintella •

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