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.

Feedback Loops in Practice

287 views

Published on

Talk held at ESUG2017 in Maribor

Published in: Software
  • Hi there! Get Your Professional Job-Winning Resume Here - Check our website! http://bit.ly/resumpro
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Feedback Loops in Practice

  1. 1. Feedback Loops in Practice Marcus Denker Talk held at ESUG2017
  2. 2. Two talks
  3. 3. ESUG14 https://www.slideshare.net/MarcusDenker/2014-esugcathedral
  4. 4. ESUG16 https://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-worse-is-better-65540840
  5. 5. (do not expect too much)
  6. 6. ESUG14
  7. 7. Scaffolding
  8. 8. ESUG16
  9. 9. Perfection
  10. 10. Feedback
  11. 11. Smalltalk can be feedback loop
  12. 12. Smalltalk should be feedback loop
  13. 13. TODAY
  14. 14. What does that mean in reality?
  15. 15. Examples for Pharo
  16. 16. What we do / what are the challenges
  17. 17. Goal: Getting feedback and ideas!
  18. 18. Trivial Changes 2014
  19. 19. Every improvement has an effect 2014
  20. 20. 2014
  21. 21. A small change fed back will have huge payout 2016
  22. 22. A tiny linear change now would be a huge change some iterations ago 2016
  23. 23. Trivial Change • Issue tracker • Make it easy to contribute • Do not ignore contributions
  24. 24. Issue Tracker • Fun: It was once thought as not needed • Record issues people have • Record contributions, too! • Open: 651 Closed: 17459 (!!)
  25. 25. Challenges • Work needed to keep clean • Duplicates, already fixed, non-actionable… • Reviewing / Getting in good state • Actually fixing reported bugs
  26. 26. Solutions • Automatic close after 1 year inactivity • Has to be automatic else people get upset • Some people look every to keep things in check • Regular Sprints: every last Friday the month • More fun to do together then alone!
  27. 27. Make it easy • It should be very easy to contribute • We are not there yet!
  28. 28. Large(r) Change
  29. 29. 2014
  30. 30. Scaffolding 2014
  31. 31. Todays system is scaffolding for tomorrow 2014
  32. 32. Elephant in the Room
  33. 33. Backward Compatibility
  34. 34. Example: Bloc/Bric
  35. 35. You can not stay 100% compatible to Morphic and do something better
  36. 36. Morphic is scaffolding to develop the next step
  37. 37. The Platform Jump to large Project1 Project2 Project3 2014
  38. 38. Nomadic Solution - Do not build infrastructure - Use resources until depleted - Move on 2014
  39. 39. The Platform Jump Possible Project1 Project2 Project3 Project4 2014
  40. 40. https://www.youtube.com/watch?v=y97rBdSYbkg
  41. 41. Backward Compatibility • Especially problematic for portable projects • Why improve the Platform if projects can only use a 100% backward compatible subset? • Is that a good situation?
  42. 42. Backward Compatibility • We need better tools and structures to support evolution of client code • Some experiments: rewriting deprecations (fun!)
  43. 43. Accept Imperfection 2016
  44. 44. 2016
  45. 45. True for both small and big small
  46. 46. Good enough to integrate • Deciding to integrate is very very hard • You do not want to reject everything • But accepting blindly is wrong, too • Lots of work!
  47. 47. Involve the community • Make it easy to review and test • Delegate reviewing to subsystem maintainers • Accept that nothing is perfect and mistakes can happen.
  48. 48. Accept Chaos • You can not control everything. There is not enough time in the day. • Things can get to be a bit chaotic at times • Yet better than limiting activity to what is controllable
  49. 49. Feedback + Chaos • Many examples where systems got into loop based exponential growth are examples lack of control: • The web vs. online services • Many examples at companies • e.g Unics vs Multics, even X86 (often examples of perfect vs. DONE).
  50. 50. Release =! Perfect • Until Pharo 6: Lots of critic from outsiders about releasing something not perfect. • But: Releases are done every year, not when everything is perfect.
  51. 51. Learned helplessness • Smalltalk is open, can be changed • Clients are programmers • People do change tools/environment • But “Smalltalk, the system” did not learn
  52. 52. Structure for Feedback
  53. 53. Structure for Feedback • Example: GT Inspector • Extending the inspector is easy • There are lots of examples • It can be done in a modular way
  54. 54. Structure for Feedback • Future Example: Sista • Implement Optimizer of the VM in the Image • Makes it easier (hopefully) for Smalltalkers to contribute
  55. 55. … round 1,000 times the global production of rice in 2010 (464,000,000 metric tons) 2016
  56. 56. If it really works…
  57. 57. … we have a problem
  58. 58. Growth: everything gets “more”
  59. 59. Challenge: Growth • More Boring tasks • More complex tasks • Require full time, long term attention
  60. 60. Solution for Scaling • Technical • e.g. Git for reviews and submissions, more people can get involved. • Community Structure • Example: Consortium • Even better solutions can be invented!
  61. 61. Input needed! • Now • At the Conference • Later by Mail or in Discord
  62. 62. Twitter: @marcusdenker http://marcusdenker.de

×