Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Loading in …3
×
1 of 50

BoS2015 Jeff Szczepanski – COO, Stack Exchange - Stack Overflow. Scaling a Technology Business is About Unscaling Technical Debt

3

Share

Download to read offline

In every successful technology businesses Jeff has worked in, the key challenge has been understanding how to scale technology and when to tackle the technical debt that inevitably accrues as a company runs ever faster and faster in pursuit of its business objectives. Jeff draws on his experience to help you understand what challenges emerge as a company moves from a Developer Centric environment to become more business focused. How can you get the business people to have influence on a developer centric environment? How can you manage the challenges that marketing will present?! What principles can you apply to be aware of problems early? How do you trade Agile Practioners vs Architectural Astronauts in a fast growing business? What are the technical debt trade-offs, what problems can you buy yourself out of? What problems will kill you if you don’t move now?

Related Audiobooks

Free with a 30 day trial from Scribd

See all

BoS2015 Jeff Szczepanski – COO, Stack Exchange - Stack Overflow. Scaling a Technology Business is About Unscaling Technical Debt

  1. 1. Scaling is about Un-Scaling Technical Debt
  2. 2. Jeff Szczepanski Chief Operating Officer talljeff@stackoverflow.com
  3. 3. Suffering from Technical Debt? • Regular Schedule Slips? • [Frequent] Need to Refactor things? • Irregular and Inconsistent Output of New Features? • Adding New Developers Doesn’t Speed Things Up? • Buggy Code and Frequent Regressions? • Ongoing Performance or Stability Problems? • Slow Turnarounds of Bug Fixes? • Bug Fixes for Your Bug Fixes?
  4. 4. Suffering from Technical Debt? What do you do?
  5. 5. REWRITE!
  6. 6. Wait, REWRITE?
  7. 7. V1.0 V2.0 V3.0 Another Kind of Technical Debt How Much Code Are You Tossing? How Much Tossing was Really Unavoidable?
  8. 8. Definition of Technical Debt Misalignment of what is easy to do with your code base and data structures vs. what you need them to do for your Product(s) to be [more] successful in the Marketplace
  9. 9. Time Features & Functionality The Hot Coals of Growth
  10. 10. Evolving Bar Of Quality 80/20 Rule 90/10 Rule 95/05 Rule 99/01 Rule
  11. 11. Customer Compelled vs. Market Focused The Debt Comes Not Just From Being Customer Compelled in Feature Definition, but it Comes from Being Customer Compelled in How Your System is Designed.
  12. 12. How Do We Ensure This? Time Features & Whole Product Quality …in the eyes of your customers
  13. 13. Key to Scaling Your Business >>> Bringing your Customers and Their Data Along With You on Your Road Map
  14. 14. Holy Wars ie: Let’s Talk About Software Process
  15. 15. Agile Good Everyone Agrees, Right? Waterfall Bad
  16. 16. Good Properties of Agile • Admits that Requirements Evolve • Encourages Regular Releases – Which allows Validation of progress more often • Sprints are Excellent for Driving Cadence • Closes the Loop Relative to Quality – Quality in all forms
  17. 17. Pitfalls of Agile • Scheduling Beyond a Few Sprints Seems Rare • Implicitly Encourages Feature Centric Thinking – At the Expense of Good System Design • Incremental Nature encourages Short Cuts – Lighter Specs, Lighter Documentation, etc. ->> Why plan or document things in too much detail when it’s just going to change anyway.
  18. 18. Good Properties of Waterfall • Formal Specifications Rule • Emphasizes Detailed Planning • System Design is specifically a thing • Highly Efficient, if Requirements are Solid
  19. 19. Pitfalls of Waterfall • Requirements are Never Perfect • Encourages Long Serial Release Cycles – Spec Everything, then Design Everything, then Build Everything, then Test Everything • Problems Discovered Late • Cost of Errors High
  20. 20. Observation • Pitfalls of Agile are pretty much the Strengths of Waterfall • Strengths of Agile are pretty much the Pitfalls of Waterfall
  21. 21. The Agile - Waterfall Continuum™ Agile Waterfall
  22. 22. Key Variables to Consider • Length of Release Cycles • Clarity/Confidence of Customer Requirements • Depth of System Complexity • How Catastrophic Are Defects? • Size of Software Team/Customer Base
  23. 23. Agile Waterfall • Requirements Discovery/Validation • Incremental Feature Delivery • Simple Systems close to UI • The progression of “dot” releases • Architecture Phases • Development of Core Services • Complex Modules far from UI • The Things that Deliver on Your Differentiation and Positioning
  24. 24. Visualizing This …and Getting a Little More Practical
  25. 25. Crazy/Hot Matrix
  26. 26. The Joel Test • Do you use source control? • Can you make a build in one step? • Do you make daily builds? • Do you have a bug database? • Do you fix bugs before writing new code? • Do you have an up-to-date schedule? • Do you have a spec? • Do programmers have quiet working conditions? • Do you use the best tools money can buy? • Do you have testers? • Do new candidates write code during their interview? • Do you do hallway usability testing?
  27. 27. Additions for Teams At Scale • Do you Document Your Services & Major Modules? – Concise Description of Role & Scope – The Full API and all the Interface Data Types – Key Design Assumptions & Dependencies – Single Person on the Team that Owns each
  28. 28. Additions for Teams At Scale • Do you Document all Your Data? – Text for Role of every Table – Text on Purpose and Invariants for Every Column – Owner that reviews every field addition/deletion
  29. 29. Additions for Teams At Scale • Do you Enforce a Coding Standard? • Do you do Code Reviews?
  30. 30. Additions for Teams At Scale • Do You Track Bugs Back to Their Source? – Closes the Loop on Quality – Looking for brittle modules – Looking for programmers in need of mentoring
  31. 31. Additions for Teams At Scale • Do you Define Deadlines and Hit Them? – Ie: Can you Make Predictable Schedules?
  32. 32. Scheduling Skeptic? Why spend time making a schedule we’ll just end up missing….we’ll put that time into the building functionality.
  33. 33. Schedule Skeptic? Why bother digging that foundation, you’re just increasing the height of the building we need to build.
  34. 34. Why Schedules are Important • Sales, Marketing, Support & Customers all care when things will ship • Good Roadmap Decisions Depend on Valid Cost/Benefit Tradeoffs
  35. 35. Why Schedules Are Important How else do you deterministically evaluate the performance of your developers or your development team?
  36. 36. Why Schedules Are Important Predictability is a Symptom of High Quality Software Development
  37. 37. Key Point Having Reliable Software Schedules is crucial to efficient scaling and continuous output. ie: Good Schedules is Good Business
  38. 38. More On Schedule & Cadence • Schedule Slips are a Learning Opportunity – Estimation is a Specific Skill, so Develop It In People • It’s Better to Do Structured Slips than Cramming • Each Team Should Have an Anchor and a Rover
  39. 39. Pulling It Together Team Organization
  40. 40. Lots of Skills at Play Here • Discovering, Developing and Finalizing Requirements • System Architecture, Design and Code Construction • Quality Control including effective testing and validation • Task Estimation and Project Management • Deployment and Ongoing Maintenance • Team Morale and the Things that Drive Cadence
  41. 41. Important Observations • Understand Performance != Results • Bunches of Separable Skills to Develop • Desire Steady Cadence & Continuous Output • Must pay attention to Motivation and Morale • Seek to Empower and Enable, not Manage
  42. 42. Three Key Roles • Developers: As team members • Team Leaders: As Player & Coaches • Engineering Managers: Skills Development
  43. 43. Team Leader • Walking Personification of Your Ideal Developer • Natural Leaders that enjoy Mentoring • Drives Cadence and Morale of the Team – Usually the Scrum Master for the Team • Responsible for Team meeting its Deadlines • In Charge of Quality of what the Team is Building • Player and a Coach -> Still Codes on the Team • Eyes and Ears for Engineering Management – Spot treatments not skills development
  44. 44. Engineering Manager • Primary Responsibility is Skills Development • Line Manager of all the Developers • Removes Operational Barriers – Helps define and deploy common tools & infrastructure • Works with a Longer Term Horizon – More Month to Month than Day to Day • Role Specializes as Organization Grows – Splits into Operational Aspects and Skills Development Aspects
  45. 45. Role Separation Team Leaders => Track Racing Pit Crew Engineering Management => Garage Mechanics
  46. 46. On Team Morale and Cadence • Bottom Up Estimates Only • Strive for Continuous and Steady Output – Expect Ownership of Goals but No Death Marches • Use Peer and Social Pressure vs. Edicts – Setting Cultural Norms and Expectations • Merit not tenure based Advancement
  47. 47. In Summary • Minimizing Technical Debt is About Matching Your Code Base and Data to your Market • Predictability Highly Correlates to Quality • Understand Performance != Results • Ultimate Goal is Developing a Suite of Strong Skills in Each Developer
  48. 48. Questions? Thank You! talljeff@stackoverflow.com @inscitekjeff

Editor's Notes

  • Before we dig in, I should introduce myself
    I’m Jeff Szczepanski, Chief Operating Officer at Stack Overflow.

    My role at Stack Overflow, as COO, is basically running “the business side” of the network. That is, there is the free service Q&A part of the company. Building out the Q&A platform itself and all the associated communities. That is headed up by Joel and several other really smart people at Stack. My half of business is all about assuming that healthy robust network exists, what do we do to make money? So sales, marketing, and products and services that we sell all falls under me.

    Relative to my own background, I’m Electrical Engineer by training, but spent most of my career as a developer, co-founder, CTO/VP of Engineering type stuff. My specialty is really in embedded real time systems development on real time operating systems. Doing hard core device drivers and network protocol stack type stuff all in C/C++.
  • Following MVP principles, you will likely get some traction, but what gets you traction there is not the same thing that leads to scalable growth of a software team
  • This is self evident to me, but people seem to debate me on this all the time.
  • ×