• Like
  • Save
Managing Creativity
Upcoming SlideShare
Loading in...5
×
 

Managing Creativity

on

  • 4,369 views

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

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.

Statistics

Views

Total Views
4,369
Views on SlideShare
4,352
Embed Views
17

Actions

Likes
2
Downloads
261
Comments
0

3 Embeds 17

http://www.linkedin.com 13
http://www.slideshare.net 3
http://www.casequiz.com 1

Accessibility

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Managing Creativity Managing Creativity Presentation Transcript

    • Managing Creativity Pycon UK, Sept 2007 Michael Sparks Kamaelia Project BBC Research
    • 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
      • 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?
      • 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!
    • 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
    • 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?
    • Building a Building
      • Sketch a design
      • Collect system requirements
      • Build models
      • Refine
      • Architect building based on physical stresses etc
      • Refine
      • Build
      • Both engineered & crafted
    • 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.
    • 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
    • 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
    • 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
    • Feature Future Proofing
      • Tests as formal spec
        • /trunk/Tests/Python/<project>/test_....
        • eg /trunk/Tests/Python/Axon/test_*
    • 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
    • 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
    • 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
    • Shared Sketchbooks /Sketches
    • 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
    • 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
    • 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
    • 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
    • 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
    • Visible Integration
    • 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”
    • Visible Integration
      • As you go through this process – more detail may emerge, and become clearer making more generally useful – better case for mainline merge
    • Hand off branches
    • Hand off branches
      • Always named
        • /branches/private_<initials>_feature
      • Never merged to /trunk by their creator, unless agreed by all admins – encourage review & feedback.
    • 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
    • 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
    • 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”