The document discusses managing creativity in software development, particularly within the context of the Kamaelia project at BBC Research. It explores the distinction between different approaches to coding, likening it to art versus engineering, and emphasizes the importance of shared sketchbooks for fostering collaboration, innovation, and effective feedback. Throughout, it highlights the role of version control and structured processes in supporting creativity while maintaining system reliability and usability.

1. Managing Creativity Pycon UK, Sept 2007 Michael Sparks Kamaelia Project BBC Research

2. Conflicting needs Research Don't know what the problem is Don't know the solution Don't know suitable approach Unknown requirements Production Know the problem inside out Have a solution which must be reliable Approach is known and engineered Requirements clear, but with scope for growth

3. Research Don't know what the problem is Don't know the solution Don't know suitable approach Unknown requirements Production Know the problem inside out Have a solution which must be reliable Approach is known and engineered Requirements clear, but with scope for growth Conflicting needs How to go from here to here?

4. Research Don't know what the problem is Don't know the solution Don't know suitable approach Unknown requirements Production Know the problem inside out Have a solution which must be reliable Approach is known and engineered Requirements clear, but with scope for growth Conflicting needs More like this!

5. Process Have an idea Build something to see if idea is good Review & build systems using it it is a good idea Make possible to use in production system Make production quality Exploration is very different from polishing

6. hackers&painters vs CS Hackers & Painters essentially postulates that coding is like painting Computer Science essentially postulates that coding is like engineering with solid foundations we can follow sound rules & constraints Both are right even though in conflict Huh?

7. Building a Building Sketch a design Collect system requirements Build models Refine Architect building based on physical stresses etc Refine Build Both engineered & crafted

8. Key Trick – Code as Wiki In python terms: Namespaces are one honking great idea -- let's do more of those! -- import this Or wiki terms: Enlarge Space - In order to preserve GlobalResources, create more public space. This reduces limited resource tension. Unlike the RealWorld, land is cheap online.

9. Core Approach Encourage play - capture results (sketchbooks) Encourage system building, component extraction Reuse & refine components Make testable Reimplement as TDD – potentially formalise tests as formal spec Version control as core enabler

10. Core Feature Flow Idea & Initial System /trunk/Sketches/<initials> Componentisation & Systems /branches/private_<initials>_Scratch (sometimes) Reuse & Candidate for main tree /branches/private_<initials>_anything Merge into Main Tree /trunk/Code

11. Feature Consolidation Testable /trunk/Code/<path>/Example/<example> /trunk/Code/<path>/Tests/test_<component>.py TDD /branches/private_<initials>_FeatureRewrite Merge /branches/private_<initials>_FeatureRewrite

12. Feature Future Proofing Tests as formal spec /trunk/Tests/Python/<project>/test_.... eg /trunk/Tests/Python/Axon/test_*

13. Feature Extension Idea /trunk/Sketches/<initials> Componentisation & Systems /branches/private_<initials>_Scratch (sometimes) Reuse & Candidate for main tree /branches/private_<initials>_anything Merge into Main Tree /trunk/Code

14. Alternative View Idea Shared Sketchbooks Componentisation & Systems Visible integration & demo of use Reuse & Candidate for main tree I'm handing this off for review Merge into Main Tree Release to general user base

15. Alternative View Idea Shared Sketchbooks Componentisation & Systems Visible integration & demo of use Reuse & Candidate for main tree I'm handing this off for review Merge into Main Tree Release to general user base Can use code for idea at all stages of development

16. Shared Sketchbooks /Sketches

17. Shared Sketchbooks: /Sketches /Sketches/MPS – this is mine, I can do what I like there. Does not have to work Can be imperfect Everyone else can see it eg /Sketches/MPS/Systems/Paint

18. Shared Sketchbooks: /Sketches /Sketches/MH – this is Matt's, he can do what he likes there. Does not have to work, can be imperfect, etc Can copy other people's sketches & extend eg /Sketches/MH/Sketcher

19. Shared Sketchbooks: /Sketches Can also play with new ideas Handwriting recognition 3D Page turning a “record for me” PVR GestureRecognition/StrokeRecogniser.py , OpenGL/3fFolding.py, DVB_PSI/PVR.py

20. Shared Sketchbooks: /Sketches Same goes for anyone else Trainee engineers Summer of code students Anyone else (you?) Can get feedback much sooner, and do fast diffs

21. What's there? Video annotating whiteboard, P2P swarming radio, IRC clients, pygame experiments, topology visualisation, paint programs, a multicast toolset, shedskin (python to C++) compatible micro-axon, simple reliable multicast experiments, sub-component level experiments, new tools for integration outside kamaelia, networked audio mixer matrix, record everything tv experiments, seaside-like HTTP server, random experiments, tools for multicast of DVB & playback, networking of pipes distribution, gesture (and basic handwriting) recognition, custom PVRs, mobile reframers, 3D video playback, PVR content viewer for mobiles, trusted communications experiments, speex tools, Icecast clients, subtitling tickers, libao tests, early 3D work, bittorrent integration work, DVB tools, weather scraping etc

22. Visible Integration

23. Visible Integration /branches/private_<initials>_Scratch Personal version of trunk – may or may not actually be shared. Benefits of sharing Not at the whims of a merger to use new namespaces Don't corrupt others Provide mechanism to demo is “OK”

24. Visible Integration As you go through this process – more detail may emerge, and become clearer making more generally useful – better case for mainline merge

25. Hand off branches

26. Hand off branches Always named /branches/private_<initials>_feature Never merged to /trunk by their creator, unless agreed by all admins – encourage review & feedback.

27. Main Code Tree: /Code Code only reaches main code tree if: Has proved itself useful in /Sketches Merge onto pseudo trunk works well Passes code review

28. Key points Always have permission to create new branches named appropriately Always have permission to check in new code “ Force of gravity” approach to consolidation Clear & simple code migration rules Version control as a tool to support process management tool

29. Key points Encourages play, encourages innovation, but in a manageable way, that also encourages development of an engineered usable system Really about “who owns a namespace”