Saturday, 24 November 2007

BarCamp London: The Transmission of Tradition - Jeremy Keith

Slides available

Jeremy gave us a great rendition with his zouk. This blog post or the slides don’t really capture it — you need musical intermissions every few minutes :-)

John Philip Sousa hated both gramaphones & radio:

  • problem was with his business model — he sold sheet music and did live performances

Irish traditional music — no tradition of making money from writing it

  • some exceptions: people writing music to celebrate a sponsor
  • most jigs, reels, etc: nobody knows who wrote them

The music was learnt aurally — still the best way to learn (all the little phrasings, etc)

Consequently, there was an enormous amount of musical variation in Ireland

Francis O’Neill, chief of police in Chicago, started collecting tunes

  • Cliche — Irish policemen in Chicago If you could play an instrument you were guaranteed a job
  • O’Neill’s 1001: “The Book” — saved music for future generations since population of Ireland was being decimated by famine and people leaving

Sharing music moved onto the internet with mailing lists

  • no music or images, so ABC format
  • software could take this format and output sheet music
  • regional variations starting to die out, since most popular lives longer

Jeremy’s contribution:

  • now 3000-4000 tunes
  • mostly public domain — some conflicts where 20th century ideas of licensing & intellectual property
  • some people will compose a tune and not take credit — hope that it gets accepted

What’s going to happen with music in the future?

  • like irish tradition? music getting out there, variations, mutations, etc
  • or like Disney? extending copyright length each time Mickey Mouse comes up for expiry

Jeremy thinks the 20th Century might be a blip

  • had the idea of the commons for a long time
  • only been 100-120 years of having false economy of scarcity

BarCamp London: Learning jQuery - Simon Willison

  • simpler than Dojo
  • Prototype & mooTools stick lots of functions in your namespace — don’t interact well

Step 1: get some stuff

e.g. jQuery('div#intro') — find DIVs with id # intro

jQuery provides lots of CSS 2&3 selectors

  • e.g. li#current ~ li (LI siblings that follow #current)

also lots of magic selectors (begin with colons)

essentially a domain-specific language for querying the DOM

Step 2: do stuff

return a jQuery collection

  • can be treated as a javascript array
  • can also call methods on it (e.g. ~.each(function() { ... }) )
  • can also modify it by calling methods like .attr()

can also control css properties & html content, including animations

using Simon’s bookmarklet called “inject jQuery” that injects the jQuery object into any HTML page live

  • can then use Firebug console to try things out interactively

jQuery also lets you introspect the DOM objects

  • e.g. can call height & width — very useful for drag & drop etc.
  • traversing DOM — parent, next, etc

in functions that you add to jQuery objects, often refer to $(this) in order to set something on the page that’s just been called

Unobtrusive javascript — get the page working without and then add a bunch of javascript to enhance the functionality

  • in order to do that, need to call javascript when DOM is ready
  • jQuery has $(document).ready(), but has been overloaded into $(function() {...}) call

jQuery allows method chaining (like LiFT) to provide concise representations, and end() method provides descoping:

  • methods that change context can then be descoped to get back to previous context
  • works well with find() method

AJAX & Animation

can load any external URI into the innerHTML of jQuery collection

can chain animations — one will happen after the other

can also roll your own animations


one to fix PNGs in IE, another to help with drag & drop

can write your own

Further reading

Good API reference —

BarCamp London: Messaging Scales – Matt Biddulph

Asynchronous messaging coming in to web (been around for a long time, esp. in banking & finance)

Concurrent languages: erlang, scala, haskell, e

If everything is done with message passing, there is no need for shared state

messaging systems:

  • dopplr uses ActiveMQ (using JSON as message bodies)
  • spread is another
  • google gears — provides local message bus for thread worker pool

long-running processes:

  • e.g. travel search, gradually fills in your results

dopplr coincidence calculations:

  • local information done immediately
  • rest of social network done by passing a message to queue
  • workers just collect and get on with it
  • if queue is too long can start up some Amazon ECS resources to process the queue for an hour or so

extreme late-binding

  • Alan Kay said that he may have overstated the objects in object orientation :-)
  • important thing is messages — work can happen anywhere if messages contain context

can have shared state using sequenced messages

  • update your own state by sending messages to the bus
  • everyone can share the same state
  • when go offline can store messages to pass, ready for when reconnect
    • can speculatively update state to present to the user
    • when reconnect can discard speculative state and catch up properly

network quake

  • short (200ms) periods of uncertainty, code guesses what will happen in that time before messages come from other players
  • guarantee that players will sync about once a second

founder of erlang: “humans are long-running processes, can pass messages, others can ignore”

OTP — built on erlang by Ericsson (who invented the language)

  • includes code changes as changes of state
  • talks about fault tolerance
  • “crash only programming”
    • don’t need shut down — just pull the plug; when start up look for any state to recover
  • like XP — a set of practices that work together

Another recommendation: Enterprise Integration Patterns by Gregor Holt

Problems with message passing:

  • only do it if the request really is async, otherwise wasting time
  • introduces dependencies on messaging system

What’s next? Matt is currently interested in Arduino

  • similar to messaging services

BarCamp London: Don't Scrape, Glean (GRDDL) - Tom Morris

APIs break the principle of DRY — equivalent to “accessible version” of web sites…

W3C have defined GRDDL: defines well-structured process of converting XHTML (or HTML4 using Tidy) into RDF * works like a stylesheet on top of your HTML

can define with GRDDL how to get at data in APIs (incl. RSS & ATOM)

aim to make data layer separate from HTML but bound to it, just like CSS

XSLT templates provided to convert HTML into RDF using classes

using xsltproc > output.rdf to transform

  • have a template HTML page that includes links to xslt
    • either your own or standard ones
  • add a link to that page in the profile attribute of the head tag of the content page
    • can have space separated profiles
  • then go to to convert page into RDF triples or JSON data

most languages have a sparql library to handle RDF pretty much like SQL


extends microformats — enables you to write your own

BarCamp London: Voluntary Economics - Reinier Zwitserloot

Slides available

According to rational economics if you are handed $10 and asked to agree a share with another person, you should offer them 1 cent. People offer much more in practice.

Some examples:

  • freakonomics - bagel guy: found that if dumped bagels, cream cheese & cash box at companies, found that at some places 95% of people paid
  • linux kernel: copyright of patches goes to Linus
  • wikipedia have got more than $1m from small donations
  • Oink: download site — couldn’t pay for music but some bands got famous based on usage
  • terra bite: pay as you wish restaurants
  • tipping…? though in America this comes with threats
  • “The Plant” — Stephen King book: published one chapter at a time, continued writing if more than 75% of downloads paid up for $1
  • article on boingboing how bartering makes banking work in Africa

counter examples:

  • web comics: have donate buttons but don’t really work

price discrimination & sales doesn’t work online

  • price discrimination — people pay the max that they are willing to pay
  • can search for coupon codes

“fame comes before fortune — if you have fame, fortune will follow”

  • that’s why micropayments don’t work as trading

Ways to get voluntary economics to work:

  • put a human face on it
  • peer pressure (e.g. tipping, bagels — had to be in public place)
  • communities — build a big one (e.g. when Starship Enterprise was canned, community raised $3m)
  • rewards based on community
  • emotion — you like it, pay money/contribute time to support

Has to be aimed at people — more emotional: corporations will just say thanks for free

Is voluntary economy a luxury good?

  • Does it only work when economy is good?
  • Maybe not — it’s a transaction since there are more things being transferred than money/time — blog is getting attention
    • —> redefine the rationality of the economic agent
  • economically more efficient

Short story from Bruce Sterling on the same area

Plug: TipIt — tip any blog

Tuesday, 20 November 2007

XPDay 2007: Specification by (executable) Example: Prosperity of the FITtest - Immo Huneke & Robert Brown

  • Using Excel spreadsheets to import data into FitNesse test fixtures
  • Wiki has “convert Excel table into wiki table” button on input, and conversely “output as Excel”
  • Now using Excel spreadsheets directly

Using FIT made tests visible and helped communication in project

FitNesse got too slow after 350ish tests!

XPDay 2007: The Secret Backlog: Behind Every Bug-Report is a User Story - Antony Marcano

  • Why not just capture acceptance tests directly from bug reports?
  • Take bugs and unexpected behaviours as prompts to talk to the customer.
  • Worked on a project for 9 months without a bug tracking system — just used acceptance tests.
  • Bugs focussed on ugly thing that system does; acceptance tests much more positive — aimed at user goals.
  • New features are easier to prioritise and nicer to work on than fixing bugs.
  • Quite often end up with new features in bug tracking system anyway…

XPDay 2007: Fiat Lux: Testing With The Light On - Joan McGalliard, George Joseph & Pushpa Sebastian

Testing team in growing agile project

Teams split according to system functionality rather than business needs

  • No one knew if a story was finished or not

30 devs, 10 testers, 7 BAs, integration team

Embedded testers in development team

At beginning of iteration wrote down stories for iteration

  • each story had page of details: acceptance criteria

Active documentation:

  • tests written in business English
  • runnable
  • italics for input, bold for output — when run, outputs are coloured red or green
  • also had table tests

Documentation is always right since if they fail, the build fails

Tests linked from stories and checked in to source control

The story process:

  1. agreeing acceptance criteria
  2. dev complete
  3. BA/show-and-tell sign off
  4. tester sign off

Can colour code iteration plan to see how far each story has got

Technology involved

Originally used FIT — introduced idea of active documentation

But inflexible, developers didn’t like fixtures

Ended up using Concordion

Tests are written using JUnit but described in an instrumented HTML page

When they fail, they give a stack trace as well as the failures on the resulting page

How to introduce

How to catch up on legacy code?

  • Forget about it — just test for current stories
  • Ended up covering criteria for previous stories too

Having tests ready in time?

  • Works best for 2 testers for every 3 developer pairs and 1 customer/BA

Takes quite a while to write the testing framework & tests

  • 50% of developer time…?

Faulty fixtures

  • Change test data and ensure test fails appropriately
  • Reuse fixtures
  • Pair testers & developers to write the tests

My thoughts: the fixtures are not visible to the customer, and the words in the active documentation do not actually have any connection to the testing code

XPDay 2007: Working With Customers towards Shared Understanding - Andy Pols & Mike Hill

This was a workshop session in which we brainstormed enablers & disablers, chose the best techniques and then talked about how we would use them and what would be the pros & cons.

Techniques that we chose:

  • user stories
  • show + tell
  • rich domain model
  • acceptance testing
  • developers using the system

XPDay 2007: Agile Alliance ATDD Tools Workshop Report - Antony Marcano

Side issue

Research in Calgary on touch-sensitive table used for agile planning (Frank Maurer)

  • enables card throwing :-)
  • create cards using tablet pc with pen-based input, then appears on shared surface to be moved around


Antony's Blog — things about testing, aggregates other blogs too


Workshop in Portland: discuss cutting-edge advancements in, and envision possibilities for, automated acceptance test driven development tools

  • Tools that help communicate & share with customers to figure out what they want
  • original name was “functional test tools workshop”

Looking at design process using tests

Had a debate: what’s the difference between an example and a test?

  • some took examples and wrapped them, others thought they were different things

Levels of abstraction

  • UCD: Goals, Activities, Tasks
  • Fit tests work better at activity rather than task level
  • Kind of translates to named methods (navigateToJourneyPlanner) vs individual “fill in field with id blah”’


  • Given, when, then
  • behaviour driven development — RSpec (ruby) in process of integrating given, when, then
  • taking hamcrest & literate tests and making a view that allows customers to interact with the tool
    • e.g. like a word processor
  • looked at JDave — didn’t feel as comfortable and natural as JUnit/Hamcrest
  • great for flow tests but not so good for:
    • do this and result in this data (row fixture in Fit)
    • truth tables — have some ideas but too immature right now
  • Nat Pryce refactored tests to be literate, next step to output Word docs from tests
  • Antony would like to enable customer to write tests (but still need conversation)
  • Nat saying that customers need to write tests in conversation with developers, so in code is good
  • thoughts: given, when, then: moving towards Z & specifications — anybody looked at synergy here?

Visualisation of flow

  • Brian Marick blog
    • currently implemented in Ruby, uses Omnigraffle so Mac-only :-)
    • draw a picture and annotate it
    • fear that if pics too detailed, then lots of refactoring needed
  • Ward Cunningham - Eclipse portal (not open source but tightly coupled to Eclipse project)
    • workflow involved in someone being nominated to be a committer on Eclipse
    • after the fact reporting on tests
      • can hover over steps and view form & data particular step
      • also have links to take you to that point in the application with data already set up
    • also used for help documentation — legal dept could see steps involved
    • actual tests captured in text-based format
  • CubicTest — Eclipse plugin to visually design tests with states
    • generates an interactive HTML prototype, based on the tests you have written
  • these tests were captured at task level, but reported at activity level

Model based testing

  • Ben Simo — state oriented model
  • Manually create state & transition model in Excel, and then generate tests from this model
  • agitator — exercises all the paths through the code (uses code as model)
    • more recent tool allows you to generate JUnit tests from suggestions, can then tidy up and rewrite
  • idea — generate a model from the first tests
    • can then generate new tests to explore the software against that model
    • helps find gaps in thinking (wouldn’t be used for auto-generating, more to suggest new tests)

Patterns of self testing software

  • talk of setting up a wiki to start capturing these ideas


  • tools will encourage appropriate level of abstraction
    • avoid refactoring overhead of writing at task level
  • will allow multiple views on tests
  • tightly integrate into documentation generated from application
  • will become more popular to make tests more transparent — available to customers
    • allows customers to provide specific examples
  • Frank Maurer has an open source project called FitClipse
  • Rick Muggridge: — refactoring Fit tests
  • Green Pepper: using Confluence to write tests (also ties in with Jira)
    • one issue was tying test versions with app versions (may be sorted with Confluence subversion plugin?)

Q&A + Comments

Concordion, decorate an HTML page with tags underneath, and then JUnit runs it

  • — open-sourced last month

Profit — supposedly allows transformation between Fit & Java for refactoring

Online discussion:

Jim Shaw/Shore has idea of customer unit tests (not end to end)

  • forcing the customer to think in modular ways

Good thing for a coach to do — encourage always asking questions

  • put on the tester hat and be persistent about asking questions
  • tester is a role that is very useful in any team

Functional tests taking a long time

  • run as separate continuous integration
  • overnight tests did full thing
  • during the day, had a different config that simplified stack and took less time

XPDay 2007: Keynote: Cheek-to-Cheek: why Co-Located Collaboration Persists - Yvonne Rogers

Video conferencing vs collocated

  • can’t talk privately to others
  • what happens after the meeting is almost or more important that during

HP Labs — mututally immersive mobile videopresence…

  • Live video of the front and sides of the user’s head
  • Mounted on a mobile robotic trolley


  • Situation awareness — aware of what’s going on around you
  • Non-verbal communication v. important to control the flow
  • Research shows that it’s easier to switch between physical & digital artifacts when face to face

Research over the last few years looking to facilitate face to face communication

eSpace — interactions between (travel) agents & customers

  • customer appears to be understanding and nodding, but really isn’t getting anything
  • a lot of translation going on from information for agent and information for customer _(hey, that’s kinda what Kizoom does :-)-
  • changed the workspace to be a side-by-side interaction with three screens
    • reduced social awkwardness
    • both looked at the screen and occasionally had eye contact
    • both took part in creating the itineraries

Theoretical approaches for supporting collocated teams

Multiple entry points

  • when each person has their own paper and pen, it becomes easy for people to share
  • when there’s only one pad, people fight over the sole entry point
  • also at whiteboards — single entry point is the marker
  • used mitsubishi diamondtouch + diamondspin s/w: touch-sensitive display table to provide shared workspace with multiple entry points
    • saw lots of turn taking and “turn inviting”
    • also people who were normally shy could take part more with the physical tasks

Distributed cognition

  • traditional approaches to cognition talk about what goes on within a single person’s head
  • distributed approach takes the system at large — lots of people with input to the group and output from them
  • distrib. cog. tries to chart:
    • where the overlaps in knowledge are
    • levels of access to information
  • this is the approach used by Helen Sharp (Yvonne is now working with her at OU)
  • Yvonne shows picture of Kizoom’s bug wall and talks about how central it was to our environment
    • (in fact this was probably a breakdown since it just filled up and didn’t get addressed…)
  • large interactive surfaces:
    • OU waiting for MS Surface (due in November, but now arriving next summer)
    • reactable — physical interaction with music software

Dynamo — collocated people sharing & showing digital content

  • shared screen with multiple mice & other devices
  • can carve out sections of the screen and protect them against others
    • can then grant and revoke access to other individual users
  • can seal parcels and leave for other users
  • deployed into a 6th form classroom
    • interaction tended to be a few people using it and others watching as an audience
  • not yet deployed into a software company, but if you want it, let Yvonne know

Conclusion & Q&A

Collocated teams will always work better than distributed teams

  • but no quantifiable effects here

What’s the value of these technologies over index cards?

  • Helen’s research shows that cards have great value that won’t go away
  • if developing a product that requires you to interact with digital content, then this tech gives an advantage
    • especially if making connections
  • people overlook emails and other digital content — posting it on a public space makes people take notice (honeypot effect — they all gather round)

What happens with larger groups?

  • Yvonne’s research is mostly with groups of 2-3
  • When groups get to 6-7 then group segments and division of labour sets in
    • “I’m working on this bit and you can work on that”

Monday, 19 November 2007

XPDay 2007: Mr Agile Goes to Washington: The Impact of Politics on Agile Projects - Panel Discussion


Sallyann Freudenberg — internal agile coach (permanently employed)

  • previously did PhD in collaborative software development
  • approach: gently let things bubble up and then deal with them

James Davison — head of PM at Razorfish (previously at ThoughtWorks)

  • has come across a lot of politics
  • don’t think you can stay out of it — perception is very important
  • try get everyone into the same space by socialising

Stuart Blair — investment bank

Mike Feathers — object mentor in US

  • travelling coach

Rachel Davies — independent coach

  • often working with several companies at one time
  • facilitating retrospectives: ensure voices are heard in a neutral way before jumping to solutions


The focus of the group seemed to be of within large corporations rather than smaller companies working with other companies.


  • covert action to get what you want from scarce resources
  • decision making process not clear — individual roles not well defined

Good politics:

  • Aligning projects with high-ups objectives
  • Finding right person to present the case on your behalf
    • Externally, this would be called sales; but internally called politics…
  • Try reframing their goals in a more positive way
    • At least lets you work with them
    • When you catch yourself saying bad things about another, it’s time to stop and step back
  • Having a strong manager who can recognise political games and call people on it
  • We often assume intentions
  • Selling the success of the project within the organisation
    • We find it hard to celebrate success

Bringing politics into our practices:

  • We don’t really have a lexicon for political behaviour…
    • Need a rudimentary politics for software developers
  • Getting to Yes — by Roger Fisher (from Harvard Law School)
    • also others in series (Getting Past No, etc)
  • Can we have a patterns book for politics…?
  • De-politicising a situation:
    • Listening
    • System thinking — showing how things all fit together

In any group have a tension between wanting to belong to a group and wanting to be an individual

Dealing with customers who play games?

  • Build a relationship with them
    • Delivering to 11 countries
    • Turned up in Austria — greeted on front door of building: you’re here to implement a system that means the office will be run from London; go away
    • Had to do a sales job; had to get sponsor on phone to convince him
  • Very difficult to build a relationship with someone when hiding something
  • Can bank integrity in relationship
  • Ask questions of everybody in the company
    • Find different points of view
    • Understand perspective of lots of different people

How do we get recognition within hero-based culture?

  • Always have to sell success (even if not being massively successful)
    • what we are delivering is useful, provides value, ready on time
  • some clients have culture of celebration when a project is completed
  • agile projects release often and regularly
    • need to celebrate that
    • tie in to business successes
  • hold an end of year retrospective
    • show off all that has been achieved
    • lots of issues overcome, just not by panicking
  • hero culture can cause problems — expose the problems and compare with smooth delivery
  • make time to be seen to be doing a good job — and build that in to project planning
    • regular show and tell

What to do when gantt chart and burn down chart start to disagree?

  • agile bubble in a non-agile company
  • often pressure for report comes from middle management: just query with higher management
  • use extra features and benefits of agile methods to sell
  • if the agile project is the first to report that it’s running late…?
    • be honest — hard conversation early on (risk of getting fired)
    • speak their language (e.g. use gantt chart)
    • that’s the project manager’s job
    • it’s going to be late or you can have this instead
    • saying “no” in a way that can be accepted

XPDay 2007: The Social Nature of Agile Teams - Elizabeth Whitworth

Why are agile developers so excited?

  • What aspects of agile dev are related to team cohesion?
  • What makes a team really gel on a project?

Speed & ease of interaction:

  • whole team involvement
  • trust, openness, respect
  • culture of action & change
    • immediate action that they could take in the near future
    • individuals could see themselves make a change
  • agile participants had a more collective viewpoint

Social identity theory

  • in-group out-group bias: just naming different groups biases the dynamic
  • agile culture increases the strength of the project group identity rather than dev, biz, etc


Planning game makes the conflicts more visible and allows developers to take more ownership over development process

Planning responds to team needs — tasks are neither to hard (anxiety) or too easy (boredom) — increases feeling of flow

Short term planning increased willingness to compromise — team interactions more relaxed

  • increased feelings of security & comfort

Long term planning hard to do as a team

  • gives rise to feelings of insecure, apprehension, stress
  • having to make decisions for things 6 months in advance

Regular Iterations

No definite end goal caused loss of “buzz” — group motivation & focus hard to maintain

Consistent delivery over multiple iterations gave rise to feelings of confidence & security

Whole team awareness

Constant feedback to individuals that all team members share awareness of team activity & share commitment to goals

Supported by daily group standup:

  • Forum for non-task based issues
  • Extra motivation (disapproval from team) and validation of requests
  • Recognition of what’s possible and what’s not
  • Communication is not need-based — allows other topics

Group standup supported by chunked activities

  • Something to report if small enough chunks
  • Loss of motivation if stuck on same task for whole week

Information Radiators: noticeable measures of progress

  • completed stories “give endorphin rush”
  • also supports awareness of individual contributions to team goal (others as well as self)


Increased sense of control & self-efficacy improves performance

Conclusion & Questions

Have a list of weaknesses at end of project, for example:

  • agile focussed on developers — makes them feel good, but QA & documentation felt isolated
  • high-level of interaction sometimes resulted in burn-out

Data collected from:

  • 5 participants from one company
  • 17 participants each from different companies

Agile is a method that helps people work as a team in the software development environment

Frank Maurer (Uni. Calgary): agile planner — distributed planning for agile teams

XPDay 2007: Building a Ubiquitous Language Using Naked Objects - Dan Haywood

Irish Govt’s Dept of Social & Family Affairs are very committed to agile


  • Eric Evans’s Domain Driven Design — tackling the complexity of the domain itself … not even specific features
  • Martin Fowler — models are just a map of the real world, they “are not right or wrong, just more or less useful”
  • “Ubiquitous language” aims to unify the vocabulary between business and developers


  • Uses reflection APIs to expose domain objects directly in user interfaces
    • (Written in Java 1.1 so can be exposed as a .net dll)
  • Goes beyond CRUD as can expose public methods as actions on objects
  • DSFA had a green screen environment previously, so any user interface was an advantage…
  • Generic user interface:
    • repositories down the left (can locate entities by type)
    • then window shows representation of entity with properties and references to other entities
    • also shows actions on properties (e.g. name —> “Legal change of name”)
    • generic interface needs training to use, but can be skinned
    • protocol between client and server is pluggable
      • Irish system is stateless, has optimistic locking and doesn’t get updates live
  • used to build self-contained apps to demonstrate
    • but customers didn’t have enough experience/installed software to properly understand the application
    • so built Wink demos to use in browser’s flash plugin

Development Environment

  • Based in Eclipse with plugins
  • Uses Spring to tie things together
  • Use fixtures for test data — use composite pattern so can reuse over user stories
  • Can build as Swing app, web app based on Jetty or RCP app

Business rules available:

  • Can hide or disable properties
  • Can validate before accepting
  • Uses modify before set — in order to set up bi-directional relations

Sister projects:

  • Naked RCP
  • Naked REST — exposes Naked Objects as RESTful web interface
    • Dan’s project for 2008…


As default user interface becomes good enough, discussion turns to domain model instead.

Wizards are for transient apps (Inmates are running the asylum — Cooper)

  • Sovereign apps gets used everyday, all the time
  • Naked objects are good for sovereign app and building the domain model (not so good for wizards)
  • Could then add a custom object that maintains its own state for building a wizard, or else use POJOs that were generated from within some other framework
  • Use Naked Objects for building and debugging the domain model


Are there any compromises in order to use Naked Object UI?

  • Navigating large collections can be awkward
  • Probably want to alter the domain slightly — view most recent, search by date — rather than view all

Since can code quickly, can actually think of pair programming with your customer

What advantages does Naked Objects give over Rails?

  • originally, MVC controller was to control the objects; been distorted so that it now controls the user
  • Naked Objects allows you to adjust domain easily independent of user controller
  • Rails insists on a user controller or just offers CRUD

XPDay 2007: Embrace Uncertainty - Jeff Patton

I came in 10 minutes late for this keynote. Train problems…

Results of stories don’t need to completely satisfy the customer — the aim is to get value and reduce risk. Iteration retrospectives should evaluate on these two goals:

  • Did we get some value? Could we get more value? Biz should answer this.
  • Did we reduce risk?

It’s ok to do the simplest possible thing that could possibly work, rather than the simplest thing that could be released.

Three different customer prioritising strategies:

  1. Follow the money — go for a single business benefit at a time
    • cuts out whole swathes of stories and simplifies iterations
  2. Don’t choose your solution too early — look at what the user wants to accomplish and defer choices as late as possible
  3. Build up feature quality iteration by iteration — need everything but can build up quality and complexity
    • e.g. building a bus — can’t
    • e.g. leave out AJAXy stuff until later, improve performance gradually
    • if build to ideal quality in each iteration then may miss out vitally important function
    • customers say “great, it’s done, let’s move on”
      • so have a report card across the features: D to A
      • can say to customers, “you have your X but it’s D quality now. You’d really want better”

As soon as you start to be dogmatic about following the process, you’re dead!


What’s your idea of the role of business analyst in agile?

  • in commercial software company like Yahoo, there’s no such thing — instead they have designers
  • would like to see BAs take more design responsibility for what they’re doing
  • in enterprise software houses, have business people talking to BAs, talking to developers

How do you deal with multiple business voices?

  • use user-centred design & scrum product owner
  • product owner takes responsibility for direction of product
  • understands the different factions and can answer to them why the development is going in that direction

In Yahoo, have designers but also product managers — how do they fit in and can we learn from them?

  • they choose direction of business value from choices given by designers

If stay uncertain, how much is it going to cost?

  • strategies outlined before came out of fixed price projects
  • play space is users to support, kinds of things to do, quality of resulting product, etc

See Jeff Patton's blog version for more details