This document summarizes Marcus Denker's talks on feedback loops at ESUG conferences in 2014 and 2016. Some key points: - Smalltalk should utilize feedback loops where the system and tools can easily evolve based on user feedback. - Maintaining backward compatibility can limit improvements, so some breaking changes may be needed while providing migration paths. - Imperfect changes are acceptable if they integrate user feedback and keep the system evolving. Involving the community helps improve changes. - As a project grows, handling increased tasks, complexity, and contributions requires technical solutions like Git and improved community structures like consortiums. The goal is to keep the system operating as a feedback loop that scales.

1. Feedback Loops
in Practice
Marcus Denker
Talk held at ESUG2017

2. Two talks

3. ESUG14
https://www.slideshare.net/MarcusDenker/2014-esugcathedral

4. ESUG16
https://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-worse-is-better-65540840

5. (do not expect too much)

6. ESUG14

9. Scaffolding

10. ESUG16

11. Perfection

12. Feedback

13. Smalltalk can be feedback
loop

14. Smalltalk should be
feedback loop

15. TODAY

16. What does that mean in
reality?

17. Examples for Pharo

18. What we do / what are the
challenges

19. Goal: Getting feedback and
ideas!

20. Trivial Changes
2014

21. Every improvement has an
effect
2014

22. 2014

23. A small change fed back will
have huge payout
2016

24. A tiny linear change now would be
a huge change some iterations ago
2016

25. Trivial Change
• Issue tracker
• Make it easy to contribute
• Do not ignore contributions

26. Issue Tracker
• Fun: It was once thought as not needed
• Record issues people have
• Record contributions, too!
• Open: 651 Closed: 17459 (!!)

27. Challenges
• Work needed to keep clean
• Duplicates, already fixed, non-actionable…
• Reviewing / Getting in good state
• Actually fixing reported bugs

28. 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!

29. Make it easy
• It should be very easy to contribute
• We are not there yet!

30. Large(r) Change

31. 2014

32. Scaffolding
2014

33. Todays system is scaffolding
for tomorrow
2014

35. Elephant in the Room

36. Backward Compatibility

37. Example: Bloc/Bric

38. You can not stay 100% compatible
to Morphic and do something better

39. Morphic is scaffolding to
develop the next step

40. The Platform
Jump to large
Project1
Project2
Project3
2014

41. Nomadic Solution
- Do not build infrastructure
- Use resources until depleted
- Move on
2014

42. The Platform
Jump Possible
Project1
Project2
Project3
Project4
2014

43. https://www.youtube.com/watch?v=y97rBdSYbkg

44. 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?

45. Backward Compatibility
• We need better tools and structures to support
evolution of client code
• Some experiments: rewriting deprecations (fun!)

46. Accept Imperfection
2016

47. 2016

48. True for both small and big
small

49. 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!

50. Involve the community
• Make it easy to review and test
• Delegate reviewing to subsystem maintainers
• Accept that nothing is perfect and mistakes can
happen.

51. 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

52. 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).

53. 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.

54. Learned helplessness
• Smalltalk is open, can be changed
• Clients are programmers
• People do change tools/environment
• But “Smalltalk, the system” did not learn

55. Structure for Feedback

56. Structure for Feedback
• Example: GT Inspector
• Extending the inspector is easy
• There are lots of examples
• It can be done in a modular way

57. Structure for Feedback
• Future Example: Sista
• Implement Optimizer of the VM in the Image
• Makes it easier (hopefully) for Smalltalkers to
contribute

58. … round 1,000 times the global production of rice in 2010
(464,000,000 metric tons)
2016

59. If it really works…

60. … we have a problem

61. Growth: everything gets
“more”

62. Challenge: Growth
• More Boring tasks
• More complex tasks
• Require full time, long term attention

63. 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!

64. Input needed!
• Now
• At the Conference
• Later by Mail or in Discord

65. Twitter: @marcusdenker
http://marcusdenker.de