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
Marcus Denker
Talk held at ESUG2017
Two talks
ESUG14
https://www.slideshare.net/MarcusDenker/2014-esugcathedral
ESUG16
https://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-worse-is-better-65540840
(do not expect too much)
ESUG14
Scaffolding
ESUG16
Perfection
Feedback
Smalltalk can be feedback
loop
Smalltalk should be
feedback loop
TODAY
What does that mean in
reality?
Examples for Pharo
What we do / what are the
challenges
Goal: Getting feedback and
ideas!
Trivial Changes
2014
Every improvement has an
effect
2014
2014
A small change fed back will
have huge payout
2016
A tiny linear change now would be
a huge change some iterations ago
2016
Trivial Change
• Issue tracker
• Make it easy to contribute
• Do not ignore contributions
Issue Tracker
• Fun: It was once thought as not needed
• Record issues people have
• Record contributions, too!
• Open: 65...
Challenges
• Work needed to keep clean
• Duplicates, already fixed, non-actionable…
• Reviewing / Getting in good state
• A...
Solutions
• Automatic close after 1 year inactivity
• Has to be automatic else people get upset
• Some people look every t...
Make it easy
• It should be very easy to contribute
• We are not there yet!
Large(r) Change
2014
Scaffolding
2014
Todays system is scaffolding
for tomorrow
2014
Elephant in the Room
Backward Compatibility
Example: Bloc/Bric
You can not stay 100% compatible
to Morphic and do something better
Morphic is scaffolding to
develop the next step
The Platform
Jump to large
Project1
Project2
Project3
2014
Nomadic Solution
- Do not build infrastructure
- Use resources until depleted
- Move on
2014
The Platform
Jump Possible
Project1
Project2
Project3
Project4
2014
https://www.youtube.com/watch?v=y97rBdSYbkg
Backward Compatibility
• Especially problematic for portable projects
• Why improve the Platform if projects can only
use ...
Backward Compatibility
• We need better tools and structures to support
evolution of client code
• Some experiments: rewri...
Accept Imperfection
2016
2016
True for both small and big
small
Good enough to integrate
• Deciding to integrate is very very hard
• You do not want to reject everything
• But accepting ...
Involve the community
• Make it easy to review and test
• Delegate reviewing to subsystem maintainers
• Accept that nothin...
Accept Chaos
• You can not control everything. There is not
enough time in the day.
• Things can get to be a bit chaotic a...
Feedback + Chaos
• Many examples where systems got into loop
based exponential growth are examples lack of
control:
• The ...
Release =! Perfect
• Until Pharo 6: Lots of critic from outsiders about
releasing something not perfect.
• But: Releases a...
Learned helplessness
• Smalltalk is open, can be changed
• Clients are programmers
• People do change tools/environment
• ...
Structure for Feedback
Structure for Feedback
• Example: GT Inspector
• Extending the inspector is easy
• There are lots of examples
• It can be ...
Structure for Feedback
• Future Example: Sista
• Implement Optimizer of the VM in the Image
• Makes it easier (hopefully) ...
… round 1,000 times the global production of rice in 2010
(464,000,000 metric tons)
2016
If it really works…
… we have a problem
Growth: everything gets
“more”
Challenge: Growth
• More Boring tasks
• More complex tasks
• Require full time, long term attention
Solution for Scaling
• Technical
• e.g. Git for reviews and submissions, more
people can get involved.
• Community Structu...
Input needed!
• Now
• At the Conference
• Later by Mail or in Discord
Twitter: @marcusdenker
http://marcusdenker.de
Feedback Loops in Practice
Feedback Loops in Practice
Feedback Loops in Practice
You’ve finished this document.
Download and read it offline.
Upcoming SlideShare
What to Upload to SlideShare
Next
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

Share

Feedback Loops in Practice

Download to read offline

Talk held at ESUG2017 in Maribor

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • 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

Talk held at ESUG2017 in Maribor

Views

Total views

744

On Slideshare

0

From embeds

0

Number of embeds

8

Actions

Downloads

1

Shares

0

Comments

0

Likes

0

×