Propose a Session (2012)

Based upon the feedback from last year, many people are interested in more in depth technical sessions as well as the opportunity to propose learning and knowledge sharing ahead of the conference.

We’re looking for enthusiastic people to run sessions on new technologies or ways of working, based upon their practical experiences.

We are particularly focusing on iterative and incremental development. How do we get feedback fast without the software getting so impenetrable that the project grinds to a halt or grinds on endlessly in mediocrity.

Sessions could include topics around technical practices e.g. testing, TDD, refactoring, build and deployment automation or the teamwork practices a technical team needs to do that well and continually improve, e.g. retrospectives, collaborative design, egoless development, specification by example, or others.

If that sounds like you, please submit a summary of your session idea, brief plan and goals as a comment on this page.

What would you like to learn?

What do you want to share with others?

How would you want to do this?

  • technical session
  • experience report
  • magazine article
  • open space

What equipment do you need?

When do you want to run your session?

  • Monday 26-Nov Morning
  • Monday 26-Nov Afternoon
  • Tuesday 27-Nov Morning
  • Tuesday 27-Nov Afternoon

19 Comments on “Propose a Session (2012)”

  1. keithb says:

    Son of the Return of TDD as if You Meant It III in 3D

    What would you like to learn?
    * How to effectively coach programmers in TDD

    What do you want to share with others?
    * What happens to code when it’s really intensively test-driven

    How would you want to do this?
    * technical session, see http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/
    at this session the rules will be refined (again) based on feedback from other sessions, most recently London Soft. Craft., to emphasize getting round the feedback loop as quickly and frequently as possible. Also, I will try to lead people more quickly to the first test as a group exercise but without “stealing the a-ha!”

    What equipment do you need?
    * Screen and Projector
    * a room in which people can comfortably do pair-programming without:
    * being all crammed in, and therefore
    * far, far too hot

    When do you want to run your session?
    * Monday 26-Nov Afternoon
    * experience at other shows suggests that half a day is not too long to really see the benefit of the session

  2. keithb says:

    any chance of turning on some text formatting in these boxes?

    • marcj says:

      Hi Keith,

      We’ve been investigating turning on formatting and so far haven’t found a way to do this. We are looking at possibly having a wiki for session ideas. I will update here when I know more.

      Thanks

      Marc

  3. Steve Smith says:

    “The Strangler Pipeline – how to Continuously Delivery greenfield and legacy applications en masse”

    What would you like to learn?
    If other people can relate to the technical and people challenges associated with scaling Continuous Delivery

    What do you want to share with others?
    A warts-and-all experience report, largely copy and pasted from a previous 30 minute presentation at Sky Horizons 2012 (http://skyagilehorizons.co.uk/) and my perpetually-in-draft Strangler Pipeline series at http://www.stephen-smith.co.uk/the-strangler-pipeline-introduction/.

    How would you want to do this?
    A 45 minute experience report featuring:
    a) some slides describing how we scaled Continuous Delivery to handle a large estate – high level technical details, low level people details
    b) some attendee experiences of Continuous Delivery

    What equipment do you need?
    A screen and a projector. An audience with their own Continuous Delivery stories to share.

    When do you want to run your session?
    Tues 26 Nov afternoon, perhaps?

  4. j says:

    Why and how to use “”Cost of Delay”” to better understand the value and urgency of the features you could be developing – and using that understanding to make better decisions.

    What we’ve learned from using this across a $100m p.a. portfolio for a Fortune 500 company.

    Intended audience: Anyone involved in making decisions in the software development lifecycle.

    • marcj says:

      Hi J,

      This looks like a good idea for an open space or experience report, please can you expand upon it.

      It would be great if you could post using your full name so that if you are registering to attend we know who you are. If there is any reason why you cannot do this, please e-mail me at xpday@marcj.co.uk

      Thanks

      Marc

  5. Ozlem Yuce says:

    Lean and the Enterprise: Maersk Line’s journey

    Learn about the journey that the world’s largest shipping company, Maersk Line, have taken so far in testing, implementing and learning about Lean-Agile across the whole organisation.
    Maersk Line operates the world’s largest container shipping fleet, with 325 offices in 125 countries, with a turnover of $26 billion per year. Maersk Line IT has over 20 development teams spread around the world with a mix of onshore/offshore and thin outsourcing.

    The Wrath of Waterfall: Historical view of how we worked
    First Contact: A giant project (X-Leap) – what we learned. what worked, what didn’t
    The Search for Agility: LPD – piloting eight Lean Product Development practices
    The Final Frontier: The Enterprise! Agility at scale (rolling out across the organisation, scaling and centralising key components)
    Next Generation: LPD 2.0 (what we’re doing now, where we’re heading)

  6. Nat Pryce says:

    ## Property-Based TDD As If You Really Meant It

    # Overview

    A workshop in which we run Keith Braithwaite’s TDD As If You Really
    Meant It session using property-based testing tools and reflect on how
    property-based testing changes the TDD process compared to
    example-based testing.

    # Introduction

    When TDD was introduced in the late 1990s, it was in terms of
    example-based testing tools, such as the xUnit family of frameworks.
    Since then, powerful property-based testing tools have become widely
    available. Originating with the QuickCheck library for Haskell,
    property-based testing tools have now been ported to all major
    languages (and many minor languages).

    These tools have not been adopted by the TDD community. Why is this?
    Are we TDD practitioners stuck in a late-’90s XP-shaped rut? Do we
    dismiss anything that was not invented by a Smalltalker? Or are
    property-based testing tools just not as well suited to the TDD
    process as example-based tools? How does a property-based testing tool
    affect the TDD process & the designs that the process drives?

    We don’t know. Let’s find out!

    # Schedule.

    0:00 – 0:15 Presentation. Introduce property-based testing tools, the
    rules of TDD as if you meant it & property-based TDD with QuickCheck
    or JUnit 4 Theories

    0:15 – 1:00 – First coding period. (Presenters go around encouraging
    participants to follow the rules of TDD As If You Meant It).

    1:00 – 1:15 – Discussion. What’s hard? How does it compare to TDD with
    examples? Anyone got *anywhere*? Share what we’ve learned.

    1:15 – 2:30 Continue coding, maybe trying a new approach based on what
    everyone has shared.

    2:30 – 3:00 Show and Tell & discussion.
    * How do property-based testing tools change TDD?
    * Do some coding styles, languages or problems make it easier to use
    property-based testing in a TDD style?
    * Does property-based testing push your design in any particular direction?
    * How can we change the exercise to better explore property-based TDD?

    # Further Reading

    Koen Claessen and John Hughes (2000). “QuickCheck: A Lightweight Tool
    for Random Testing of Haskell Programs” (PDF). Proc. Of International
    Conference on Functional Programming (ICFP), ACM SIGPLAN.
    [http://www.cs.tufts.edu/~nr/cs257/archive/john-hughes/quick.pdf]

    QuickCheck for various programming languages.
    [http://en.wikipedia.org/wiki/QuickCheck]

    The Practice of Theories: Adding “For-all” Statements to
    “There-Exists” Tests (David Saff, Marat Boshernitsan) Submitted to
    IEEE Software, Special Issue on Test-Driven Development.
    [http://shareandenjoy.saff.net/2006/12/new-paper-practice-of-theories.html]

    • Nat Pryce says:

      I think we should run it on
      the second afternoon and announce it on the first day to give people a
      chance to install libraries for their favourite language before the
      session, so we have a chance to hit the ground running. I’ll prepare
      projects for Java and Python and have them on USB sticks that people
      can copy onto their laptops.

    • I’d prefer this to go ahead in preference to the usual TDD as if you meant it (but would be happy to do TDDaiYMI if this doesn’t make the cut).

  7. ## Introduction to Behaviour Driven Development (BDD) with Cucumber

    I’ve built plenty of software systems using BDD and cucumber now, and run training for both the BBC and publicly as BDD Kickstart[1] with Matt Wynne. I’d love to run an introductory practical session teaching people the basics of Cucumber with BDD and how to apply it to their contexts.

    I particularly want to focus on:

    a) how to write a great feature
    b) how to ensure that your features are maintainable over time, to avoid your tests crashing to a halt and inhibiting your project
    c) How you practically apply TDD within the BDD context.

    I want to end with a practical session working through building an example application in Ruby.

    We’ll be working in pairs and at least one of each pair will need a laptop with a sane ruby environment set up.

    I’m only around on Monday 26th until about 3:30pm I’m afraid, so I’d love to run this Monday morning.

    Thanks for considering!

    [1] http://bddkickstart.com

    • marcj says:

      Hi Chris,

      This session looks good and it would be great if you would run this on the Monday morning.

      Is there any other equipment you need for the session?

      Do participants need anything other than ruby on there machine, gems etc?

      Thanks

      Marc

      • marcj says:

        Hi Chris,

        Also, I’d love to put some more info up on the schedule page, please can you either post here or mail me (xpday@marcj.co.uk).

        Thanks

        Marc

      • chrismdp says:

        Hi Marc,

        The participants will only need a sane version of ruby 1.8.7 or above on their machines. The example app that I use has all the gems locally on a USB stick, or they can grab them from a github repository and use bundler – should be painless.

        Anything else you need to know?

      • marcj says:

        Thanks Chris,

        I don’t think so, their is a description up on the schedule page, which should be fine (please let me know if you want it changing).

        Marc

      • chrismdp says:

        Hi Marc,

        Why don’t we start this at 10:15 rather than 9:30, so that participants don’t miss the opening circle?

        Chris

      • marcj says:

        Hi Chris,

        Good idea, I’m happy to change it if you are. I will update the schedule.

        Thanks

        Marc

  8. Knowledge Map of Software Engineering paradigms

    What would you like to learn?

    Can we discover connections between ideas that help us understand them better:
    ie Does reading Alan Kay’s writings on OOP help us with GOOS

    What do you want to share with others?

    What I’ve discovered so far.

    How would you want to do this?

    Workshop with a wall and some index cards


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s