Managing Creativity

2,903 views
2,742 views

Published on

In this talk I talked about how,in the Kamaelia project, we manage the dilemma of encouraging innovation and creativity in a project whilst maintaining an engineered solution. Why? Because we find it allows a high level of creative freedom, whilst also providing a path through to a high level of confidence in the reliabilty of the final code.

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,903
On SlideShare
0
From Embeds
0
Number of Embeds
45
Actions
Shares
0
Downloads
264
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Managing Creativity

  1. 1. Managing Creativity Pycon UK, Sept 2007 Michael Sparks Kamaelia Project BBC Research
  2. 2. Conflicting needs <ul><li>Research </li></ul><ul><li>Don't know what the problem is </li></ul><ul><li>Don't know the solution </li></ul><ul><li>Don't know suitable approach </li></ul><ul><li>Unknown requirements </li></ul><ul><li>Production </li></ul><ul><li>Know the problem inside out </li></ul><ul><li>Have a solution which must be reliable </li></ul><ul><li>Approach is known and engineered </li></ul><ul><li>Requirements clear, but with scope for growth </li></ul>
  3. 3. <ul><li>Research </li></ul><ul><li>Don't know what the problem is </li></ul><ul><li>Don't know the solution </li></ul><ul><li>Don't know suitable approach </li></ul><ul><li>Unknown requirements </li></ul><ul><li>Production </li></ul><ul><li>Know the problem inside out </li></ul><ul><li>Have a solution which must be reliable </li></ul><ul><li>Approach is known and engineered </li></ul><ul><li>Requirements clear, but with scope for growth </li></ul>Conflicting needs How to go from here to here?
  4. 4. <ul><li>Research </li></ul><ul><li>Don't know what the problem is </li></ul><ul><li>Don't know the solution </li></ul><ul><li>Don't know suitable approach </li></ul><ul><li>Unknown requirements </li></ul><ul><li>Production </li></ul><ul><li>Know the problem inside out </li></ul><ul><li>Have a solution which must be reliable </li></ul><ul><li>Approach is known and engineered </li></ul><ul><li>Requirements clear, but with scope for growth </li></ul>Conflicting needs More like this!
  5. 5. Process <ul><li>Have an idea </li></ul><ul><li>Build something to see if idea is good </li></ul><ul><li>Review & build systems using it it is a good idea </li></ul><ul><li>Make possible to use in production system </li></ul><ul><li>Make production quality </li></ul><ul><li>Exploration is very different from polishing </li></ul>
  6. 6. hackers&painters vs CS <ul><li>Hackers & Painters essentially postulates that coding is like painting </li></ul><ul><li>Computer Science essentially postulates that coding is like engineering with solid foundations we can follow sound rules & constraints </li></ul><ul><li>Both are right even though in conflict </li></ul><ul><li>Huh? </li></ul>
  7. 7. Building a Building <ul><li>Sketch a design </li></ul><ul><li>Collect system requirements </li></ul><ul><li>Build models </li></ul><ul><li>Refine </li></ul><ul><li>Architect building based on physical stresses etc </li></ul><ul><li>Refine </li></ul><ul><li>Build </li></ul><ul><li>Both engineered & crafted </li></ul>
  8. 8. Key Trick – Code as Wiki <ul><li>In python terms: </li></ul><ul><li>Namespaces are one honking great idea </li></ul><ul><li>-- let's do more of those! -- import this </li></ul><ul><li>Or wiki terms: </li></ul><ul><li>Enlarge Space - In order to preserve GlobalResources, create more public space. This reduces limited resource tension. Unlike the RealWorld, land is cheap online. </li></ul>
  9. 9. Core Approach <ul><li>Encourage play - capture results (sketchbooks) </li></ul><ul><li>Encourage system building, component extraction </li></ul><ul><li>Reuse & refine components </li></ul><ul><li>Make testable </li></ul><ul><li>Reimplement as TDD – potentially formalise tests as formal spec </li></ul><ul><li>Version control as core enabler </li></ul>
  10. 10. Core Feature Flow <ul><li>Idea & Initial System </li></ul><ul><ul><li>/trunk/Sketches/<initials> </li></ul></ul><ul><li>Componentisation & Systems </li></ul><ul><ul><li>/branches/private_<initials>_Scratch (sometimes) </li></ul></ul><ul><li>Reuse & Candidate for main tree </li></ul><ul><ul><li>/branches/private_<initials>_anything </li></ul></ul><ul><li>Merge into Main Tree </li></ul><ul><ul><li>/trunk/Code </li></ul></ul>
  11. 11. Feature Consolidation <ul><li>Testable </li></ul><ul><ul><li>/trunk/Code/<path>/Example/<example> </li></ul></ul><ul><ul><li>/trunk/Code/<path>/Tests/test_<component>.py </li></ul></ul><ul><li>TDD </li></ul><ul><ul><li>/branches/private_<initials>_FeatureRewrite </li></ul></ul><ul><li>Merge </li></ul><ul><ul><li>/branches/private_<initials>_FeatureRewrite </li></ul></ul>
  12. 12. Feature Future Proofing <ul><li>Tests as formal spec </li></ul><ul><ul><li>/trunk/Tests/Python/<project>/test_.... </li></ul></ul><ul><ul><li>eg /trunk/Tests/Python/Axon/test_* </li></ul></ul>
  13. 13. Feature Extension <ul><li>Idea </li></ul><ul><ul><li>/trunk/Sketches/<initials> </li></ul></ul><ul><li>Componentisation & Systems </li></ul><ul><ul><li>/branches/private_<initials>_Scratch (sometimes) </li></ul></ul><ul><li>Reuse & Candidate for main tree </li></ul><ul><ul><li>/branches/private_<initials>_anything </li></ul></ul><ul><li>Merge into Main Tree </li></ul><ul><ul><li>/trunk/Code </li></ul></ul>
  14. 14. Alternative View <ul><li>Idea </li></ul><ul><ul><li>Shared Sketchbooks </li></ul></ul><ul><li>Componentisation & Systems </li></ul><ul><ul><li>Visible integration & demo of use </li></ul></ul><ul><li>Reuse & Candidate for main tree </li></ul><ul><ul><li>I'm handing this off for review </li></ul></ul><ul><li>Merge into Main Tree </li></ul><ul><ul><li>Release to general user base </li></ul></ul>
  15. 15. Alternative View <ul><li>Idea </li></ul><ul><ul><li>Shared Sketchbooks </li></ul></ul><ul><li>Componentisation & Systems </li></ul><ul><ul><li>Visible integration & demo of use </li></ul></ul><ul><li>Reuse & Candidate for main tree </li></ul><ul><ul><li>I'm handing this off for review </li></ul></ul><ul><li>Merge into Main Tree </li></ul><ul><ul><li>Release to general user base </li></ul></ul>Can use code for idea at all stages of development
  16. 16. Shared Sketchbooks /Sketches
  17. 17. Shared Sketchbooks: /Sketches <ul><li>/Sketches/MPS – this is mine, I can do what I like there. </li></ul><ul><li>Does not have to work </li></ul><ul><li>Can be imperfect </li></ul><ul><li>Everyone else can see it </li></ul><ul><li>eg </li></ul><ul><ul><li>/Sketches/MPS/Systems/Paint </li></ul></ul>
  18. 18. Shared Sketchbooks: /Sketches <ul><li>/Sketches/MH – this is Matt's, he can do what he likes there. </li></ul><ul><li>Does not have to work, can be imperfect, etc </li></ul><ul><li>Can copy other people's sketches & extend </li></ul><ul><li>eg </li></ul><ul><ul><li>/Sketches/MH/Sketcher </li></ul></ul>
  19. 19. Shared Sketchbooks: /Sketches <ul><li>Can also play with new ideas </li></ul><ul><ul><li>Handwriting recognition </li></ul></ul><ul><ul><li>3D Page turning </li></ul></ul><ul><ul><li>a “record for me” PVR </li></ul></ul><ul><li>GestureRecognition/StrokeRecogniser.py , OpenGL/3fFolding.py, DVB_PSI/PVR.py </li></ul>
  20. 20. Shared Sketchbooks: /Sketches <ul><li>Same goes for anyone else </li></ul><ul><li>Trainee engineers </li></ul><ul><li>Summer of code students </li></ul><ul><li>Anyone else (you?) </li></ul><ul><li>Can get feedback much sooner, and do fast diffs </li></ul>
  21. 21. What's there? <ul><li>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 </li></ul>
  22. 22. Visible Integration
  23. 23. Visible Integration <ul><li>/branches/private_<initials>_Scratch </li></ul><ul><li>Personal version of trunk – may or may not actually be shared. </li></ul><ul><li>Benefits of sharing </li></ul><ul><ul><li>Not at the whims of a merger to use new namespaces </li></ul></ul><ul><ul><li>Don't corrupt others </li></ul></ul><ul><ul><li>Provide mechanism to demo is “OK” </li></ul></ul>
  24. 24. Visible Integration <ul><li>As you go through this process – more detail may emerge, and become clearer making more generally useful – better case for mainline merge </li></ul>
  25. 25. Hand off branches
  26. 26. Hand off branches <ul><li>Always named </li></ul><ul><ul><li>/branches/private_<initials>_feature </li></ul></ul><ul><li>Never merged to /trunk by their creator, unless agreed by all admins – encourage review & feedback. </li></ul>
  27. 27. Main Code Tree: /Code <ul><li>Code only reaches main code tree if: </li></ul><ul><ul><li>Has proved itself useful in /Sketches </li></ul></ul><ul><ul><li>Merge onto pseudo trunk works well </li></ul></ul><ul><ul><li>Passes code review </li></ul></ul>
  28. 28. Key points <ul><li>Always have permission to create new branches named appropriately </li></ul><ul><li>Always have permission to check in new code </li></ul><ul><li>“ Force of gravity” approach to consolidation </li></ul><ul><li>Clear & simple code migration rules </li></ul><ul><li>Version control as a tool to support process management tool </li></ul>
  29. 29. Key points <ul><li>Encourages play, encourages innovation, but in a manageable way, that also encourages development of an engineered usable system </li></ul><ul><li>Really about “who owns a namespace” </li></ul>

×