What every developer can learn from startups

1,572 views

Published on

My talk on which aspects of agile work in startups and which don't, as well as some general rules of thumb for launching software projects

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,572
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

What every developer can learn from startups

  1. 1. What every developer can learn from startups
  2. 2. /me #1 <ul><li>Got hooked on startups at Riot-E </li></ul><ul><ul><li>Search for “riot on” on YouTube </li></ul></ul><ul><li>Startup cult member since </li></ul><ul><ul><li>30+ companies total </li></ul></ul><ul><ul><li>expert on failure </li></ul></ul>
  3. 3. /me #2 <ul><li>Do technical due diligence for investors </li></ul><ul><ul><li>get paid to criticize other's work </li></ul></ul><ul><li>Keen on JavaScript </li></ul><ul><ul><li>the older I get, the more lazy I get </li></ul></ul>
  4. 4. Why write code?
  5. 5. What drives developers? <ul><li>Self actualization </li></ul><ul><li>Respect of others </li></ul>
  6. 6. What drives managers? <ul><li>??? </li></ul><ul><li>Profit </li></ul>
  7. 7. What drives customers? <ul><li>Value (for money) </li></ul>
  8. 8. <ul><li>Software development is like ... </li></ul>
  9. 14. … Biological Systems <ul><li>Evolving, interacting systems </li></ul><ul><li>… that nobody quite understands </li></ul><ul><li>Everything somehow still works </li></ul><ul><li>… but may end up being a monster </li></ul>
  10. 15. How do projects get started? <ul><li>Somebody thinks they know what others want </li></ul><ul><ul><li>raise -> build -> sell </li></ul></ul><ul><li>Should validate their assumption first </li></ul><ul><ul><li>sell -> build -> raise? </li></ul></ul>
  11. 16. Be Lazy <ul><li>The only projects that get delivered on time and according to spec are the ones that never get started at all </li></ul>
  12. 17. Customers #1 <ul><li>You're not in the service industry </li></ul><ul><ul><li>The customer is not always right! </li></ul></ul><ul><li>Learn how to say NO , excessive customer collaboration results in bloat </li></ul><ul><ul><li>37signals vs. Salesforce </li></ul></ul>
  13. 18. Customers #2 <ul><li>Don't build just for one customer </li></ul><ul><ul><li>Discover product market fit </li></ul></ul><ul><li>You're building a long term relationship </li></ul>
  14. 19. The Team <ul><li>Communication overhead to be avoided at all costs, this increases exponentially with team size </li></ul><ul><li>Cross functional teams are great, but smaller teams of specialized generalists are better </li></ul>
  15. 20. Rockstars and Ninjas <ul><li>Developer output varies by an order of magnitude, so finding the best developers (who are nice people) is key </li></ul>
  16. 21. Expectations <ul><li>It's all about managing them </li></ul><ul><li>Very hard to do when requirements change </li></ul><ul><ul><li>Almost always means more work </li></ul></ul><ul><li>Burn-down & burn-up charts </li></ul>
  17. 24. Milestones <ul><li>Needed to achieve sense of accomplishment and self worth </li></ul><ul><li>Needed for invoicing </li></ul><ul><li>Having something working badly is better than having nothing that works well </li></ul>
  18. 25. Embarrassment <ul><li>“ If you are not embarrassed by the first version of your product, you’ve launched too late” </li></ul><ul><ul><li>Reid Hoffmann, LinkedIn </li></ul></ul>
  19. 26. Prototypes #1 <ul><li>Changes are easier to make early in the development cycle, but this gets progressively more difficult </li></ul><ul><li>Functional prototypes are great for conveying the big picture and user journey </li></ul>
  20. 27. Prototypes #2 <ul><li>Basis for a contract </li></ul><ul><ul><li>You do need those sometimes </li></ul></ul><ul><ul><li>Works even when you are your own customer </li></ul></ul><ul><li>Great for validating the customer </li></ul>
  21. 28. Features #1 <ul><li>Features are like sex </li></ul><ul><li>Less is more </li></ul><ul><li>Not every piece of work can be described as a story or a feature </li></ul>
  22. 29. Features #2 <ul><li>You can think through a feature without implementing it </li></ul><ul><li>You can build a feature without rolling it out </li></ul>
  23. 30. Modularity #1 <ul><li>Monolithic systems are hard to reason about </li></ul><ul><li>The Unix philosophy is the way forward </li></ul><ul><ul><li>Write programs that do one thing and do it well. Write programs to work together. </li></ul></ul>
  24. 31. Modularity #2 <ul><li>Creating reusable modules is the right thing to do </li></ul><ul><ul><li>Despite having no visible benefit to end users </li></ul></ul><ul><ul><li>Because you don't always want to scrap everything </li></ul></ul>
  25. 32. Open Source <ul><li>Give away everything you can </li></ul><ul><li>Promotes your business </li></ul><ul><li>Recruiting tool </li></ul><ul><li>Motivational aid </li></ul>
  26. 33. Technical Debt <ul><li>“ Eventual consequences of slapdash software architecture and hasty software development” </li></ul><ul><li>Do take on, as long as you know you're doing it </li></ul>
  27. 34. Failure <ul><li>Failure is change </li></ul><ul><li>Embrace it </li></ul><ul><li>Learn from it </li></ul><ul><li>Know when to quit </li></ul><ul><ul><li>Don't throw good money after bad </li></ul></ul>
  28. 35. Distributed Teams <ul><li>Increasing trend </li></ul><ul><li>Rockstars and Ninjas are on the road a lot </li></ul><ul><li>Meetings are evil </li></ul><ul><li>Tools can help </li></ul>
  29. 36. Operations & Metrics <ul><li>Roll out updates quickly and often </li></ul><ul><li>Trust your developers </li></ul><ul><li>It's a numbers game </li></ul><ul><li>Track everything you can </li></ul>
  30. 37. Summary <ul><li>This is not an exact science </li></ul><ul><li>Use whatever works for you </li></ul><ul><li>Think about the bigger picture </li></ul><ul><li>Enjoy the process, not the end goal </li></ul>
  31. 38. Thank you! <ul><li>@olegpodsechin </li></ul><ul><li>github.com/olegp </li></ul>

×