It was a great conference - I really enjoyed it. The Robinson Centre was a very nice place to have a conference - the rooms were comfortable, the meeting rooms were very nice, and the central lounge area was comfy - nice couches, and WiFi provided by ThoughtWorks - that WiFi setup made all these posts far easier to make than they would have been otherwise. There was a lot of interest at the Cincom booth - lots of people seemed to be pleasantly surprised that Smalltalk was alive, kicking, and ready for anything.

I suppose I should mention my own session, which ran during the last time slot - I spoke about blogs and RSS. Martin Fowler had some good suggestions for me on the organization of the slides - I'll be revising them before I give this presentation again. The discussion was very lively - as it turned out, a lot of the audience (about 20 or so) didn't have a good grasp of what RSS was before the talk. I plan to be back next year - great show, wonderful time!

Laura Hill and Bernard Horan of Sun (R&D group)

Examples

• Remote Door Bell - say you are working outside, doorbell rings. Nice if the doorbell muted the radio and rang itself on the radio (or on the mobile phone, etc). Not possible if all devices are using fully proprietary interfaces. Bernard showed his Bluetooth enabled phone controlling volume on the Bluetooth enabled notebook as an example.
• Elder hospice care facility to monitor safety/health of resident(s)
• Health stats
• Intrusions
• Fire, etc
• Small scale home security syste
• Wireless, battery operated
• Elements discover each other on net
• Each item in system does its own task (video monitiring, etc)
• Nice if it could be set up to notice "normal" anomalies (a cat, for instance, should not set off the network)
• Imaging
• Being able to easily discover an available printer on an ad-hoc (WiFi) network
• Variable pricing, etc

A 40 minute team exercise - come up with a new service/idea that plays into discoverability. We came up with the notion of personal location identification cutting across devices and locations:

• Phone (land and mobile)
• PDA
• Email
• Home and other locations recognizing you and configuring themselves to your known desires
• Privacy settings issues

First group - Jack Black finds himself in a strange city with a PDA, and may be in danger of sobering up if he does not find a bar. So his PDA should be able to have that critical information available and route him to the nearest bar:

• Local Customs (tip, etc)
• How late is bar open?
• How close? How do we get there?
• When Jack's blood alcohol level drops below a certain level it notifies him that it's time to drink. Also takes account of current monetary level, and which location is closest
• Environment needs to be able to deal with any local environment automatically. Not all locations will have services that work for this.
• Should be able to translate across language barriers
• Should have privacy, security, abiding by local laws

Second group - Intelligent Visitor Filtering doorbell

User Requirements

• Filters visitors based on context and learned preferences
• Time of Day
• State of House
• Who is present in house
• Contents of the fridge
• Learned preferences of the homeowners for visitors based on context

Task Requirements

• Need for discovery of context of house and home owner
• Need for discovery of purpose of visit
• Comparison of visit purpose with context with preferences, assessment of significance of vist for homeowner/those present

Next step - how to create a solution - the two more general groups (ours and the intelligent filtering) will need to focus in more. They gave us a large handout with a whole bunch of descriptive technology refs and Discovery Protocols. I'm not going to describe all of them.

Descriptive tech

• CCPP - with RDF (ick)
• FIPA
• JSR 124
• MIME Types
• SensorML (XML Schema)
• TinySchema

Discovery Protocols

• Bluetooth Service Discovery Protocol
• CORBA
• INS
• Java RMI
• Jini
• JXTA
• OWL-S
• Rendevous
• Salutation
• Service Location Protocol
• UPnP
• Web Services

For our scenario, we came up with Bluetooth as the best mechanism for initial broadcast of identity information - providers would then do additional queries through some other mechanism (Web Services, JXTA, whatever).

Intelligent Doorbell Scenario - doorbell is not a doorbell, but delegates the task to whatever service should find an appropriate person - it may end up being the ring by default. The person hitting the doorbell will be queried as to what they offer/want, and appropriate proxies will be notified. So with that, they went with Jini, mostly for the Pub/Sub capability. If BlueTooth did that, they would have considered it. If JXTA did that well, might consider it.

The Jack Black drinking system - Ended up with the business part (getting the alcohol) and the discovery part. Missing part - bringing up the network. Ended up a need for multiple services from the list - possibly BlueTooth, possibly Web Services, possibly OWL-S.

Notes - no one brought up security, although we did bring up privacy. There seemed to be an "assumption that it would be secure" - meaning that no one took responsibility for it :) Not that we've seen that before :)

Plenary session on 3/31 - how to design a good API - and why it matters. Given by Joshua Bloch, senior staff engineer at Sun. The need for good API's remain as languages and platforms change - what do we mean by APIs here - the public interface to a component or sub-system. There are going to be examples (good and bad) given.

Why is API design important?

• APIs can be amongst a company's greates assets
• Customers get attuned to the apis that they have studied, and write (and buy) code that is aligned with those APIs
• APIs capture and retain customers
• A badly designed API is an unending source of support calls - and public APIs are forever. Once it's loose, you can't change it - you can only add to it

If ypu program, you are an API designer. Each module you create ends up with an API - either real or ad-hoc. Useful modules tend to get reused. Once you have users, you are not at liberty to change it - people rely on it. These "private" apis can be an asset or a liability.

Good?

• Easy to learn
• Easy to use, even w/o doc
• Hard to misuse
• Bad ones will be easy to misuse
• Easy to read and maintain code that uses it
• Sufficiently powerfil to satisfy requirements
• But not too powerful
• Easy to extend
• Appropriate to audience - no such thing as a "perfect" API for everyone

Methodology for API design - there are a few things that tend to lead to good API design. Gather requirements, and be skeptical. The audience will tell you what they want (may be different from what they need). Extract the real requirements from what you get told and what you observe. Use Cases are the best way to do this - what are the easiest things to accomplish with that API? Do the Use Cases look good when using the API? If not you have a problem. It can be easier to build something more general than what you are asked for - but don't go to "framework-itis

Start with a small (1 page) spec. Agility is good at this point. Bounce the spec off of as many people as possible. Keep the spec to a short description and method names - flesh it out only as you gain confidence. Shop it around while it's simple. When you get a large spec, it's hard to change (and involves politics).
Write the API before you implement it. Saves an implementation that may be useless. Start coding to it when it's a 1 page spec to test (TDD driven API design?). Continue to write code against the API as you develop as a constant check against it.

Writing to an API (Service Provider Interface) is even more important.

• Interface for supporting multiple implementations
• Example - Java Cryptography

Keep expectations realistic. Won't be all things to all people. "Aim to displease everyone equally". Say you have 6 customers - 5 happy, one angry - not good. 6 grumbling "can work with it, but..." - likely ok. Expect to make mistakes - you'll make them, and you'll have to evolve (NOT change!) the API.

General Principles - should do one thing, and one thing well. Use good naming. If it's hard to name, it's a bad sign of code smell. Bad names mean poor understanding. Be open to refactoring (splitting and merging modules). The API should be as small as possible but no smaller (Occam's razor). When in doubt, leave it out - in terms of classes, methods, functionality - they can be added later, but once it's there, it's there. Conceptual weight is more important - how long will it take to learn the API? A Java example - if you implement an interface that is already there, people have a guide.
Implementation should not impact the API. Implementation details constrain you and confuse users. Don't over specify (e.g., don't specify the details of a hash function...). Don't let implementation details leak into the API. Exceptions, on the wire, or on disk formats are good examples where leakage can hurt. The initial Java String hash function (which they almost had to live with) was very bad. Actual is better, but still specified (bad).

Minimize accessibilty - maximize information hiding. Make instance variables private (i.e., in ST, no accessors). APIs are a "little language" - be consistent - parts of speech and basic names. Intention revealing names important.
Documentation matters, a lot. Reuse won't happen without good design and good documentation. Document every class, every interface, every method, constructor, parameter, exception (ed. - most methods should not need doc - especially internal, non API ones. API methods, likely should. IMHO, intention revealing names should do most of this). If there are state constraints, doc that, or risk unusability.

Consider performance implications of an API.

• Mutability?
• Constructor instead of static factories
• Implementation type instead of interface

ed. - These are issues that, IMHO, most people should never have to worry about....

Bad API designs are permanent. Example: In AWT, Component.getSize returns (mutable) Dimension object. Each getSize call allocates a Dimension (ed. - that's a GC issue. VW has never had an issue here....)
API's must co-exist with the platform. Obey naming conventions, avoid obsolete stuff, etc. Take advantage of any language features. Avoid any language/platform specific traps

Class Design

• Minimize mutability - classes should be immutable unless there's a good reason... not sure I agree with that...
• If mutable, keep the state space small and well defined
• Date and Calendar are bad examples
• Timer is good

Seriously, I don't know that - other than (previously mutable) Strings in Smalltalk, this is ever something I've had to worry about...

Subclass only when makes sense

• Liskov substitutability principle
• Inheritance violates encapsulation - he says you should use final - I disagree violently. To me, this is a classic engineer's mistake of assuming all possible future uses of a class or library. You can't see that. Now, admittedly, making classes interface compatible rather than inheritance compatible is safer - but "fragile base class" is more of a Java/C issue. Final is a bug.

Method design

• Don't make the client do anything the module should do - reduce need for boilerplate. There's an example of this from the DOM code in Java. If you require boilerplate, then your library is missing a few things. Think as a user of the API and encapsulate that sort of thing.
• Don't violate the "principle of least astonishment" (old Smalltalk adage :) ). Spending time on the API to make it easier is more important than performance. Example - method called "interrupted" in Thread clears state as well as reporting it.
• Fail fast - he likes strong static typing, but he's wrong :) In general, good principle goes with "least astonishment" - fail early when it makes most sense. Ironically, his properties example shows the limits of declarative typing. put() in HashTable accepts any objects, but actually enforces Strings in code.
• Don't make the client play "20 questions" when asking for state.
• Provide programmatic access to all data available in String form - otherwise people will parse them. This ends up turning those strings into a de-facto API.
• Overload with care - no two with same number of args (ed. - not a Smalltalk problem due to keyword messages :) )
• Use appropriate parameters and return types - "least astonishment"
• Favor interfaces
• Don't use Floats for money (amazing that this still comes up!)
• Use consistent parameter ordering - note again that keyword messages solve this whole problem :)
• Avoid long parameter lists - long ones cause problems (going to doc) - especially bad - long lists of identical types (again, solved by keywords...)
• Avoid return values that demand processing - he says not to return null (Wrong!) - In Smalltalk, answering nil is a well understood and widely used pattern.
• Don't use exceptions for control flow, only for errors. Don't fail silently!
• Favor unchecked exceptions. Checked exceptions cause boilerplate. See Parcel loading in Smalltalk for examples of this and the previous...
• Include failure/capture information with the exception

Refactoring
The examples are showing the Collection hierarchy in Java as a replacement for the older Vector stuff. Another example shows a cleanup of some Thread code (replace Strings and keys with key objects).

Summary
Can be rewarding and valuable for companies and teams. Suggests that these rules are guidelines, not hard and fast rules. API design is not simple. "Perfection is unachievable"

Naked Objects - a BOF session after the end of the normal day here. Naked Objects - oddball thing about the name - book lookup on Amazon yields some "interesting" nearby subjects

The idea - to get rid of all the extraneous things - reduce to the leanest, bare essentials. Four layers in classic architecture:

• Presentation
• Application/Controller
• Domain Object Model
• Persistence

Naked Objects eliminates the controller layer - encapsualtes all business functionality on the entity objects (note - this elides any issues with session access to behavior that is permission based). Make the presentation layer generic. Make the persistence layer generic. In theory, generate the presentation and persistence layers from the domain model. I detect MVC being reinvented in the Java sphere :)

An example - conference registration:

• BOF
• Delegate
• Room
• Resources
• Company

Noting that a delegate can be part of a company. The demo proceeded using Together/J to build the domain using UML (ed. - I am historically very wary of this kind of tool and development model. In particular, I find it easier and faster to just use a browser :) ). After building the four domain classes, a build yields a simple set of classes that have some basic UI behavior (not unlike a Smalltalk inspector, although less powerful than Trippy to be sure). Relationships? There's a visual programming way of doing that (like PARTS, noting that we've been there, and it doesn't scale...). Important note on that being that the Together/J linking behavior is not a necessary part of Naked Objects - it's a part of Together/J that is independent of what you are doing.

My main concern would be the assertion that we can make the UI generic. In my experience, lots of work ends up going into the UI that is only marginally related to the domain - ways that the UI can be configured by the end user (in BottomFeeder, for instance, the ability to zoom/unzoom different parts of the UI, and how that depends on the current UI state. I guess I just have a hard time with the notion of a generic UI. It flies in the face of what I've had to do with Bf.

Now a second session on ModelScope - a prototyping tool. The notion is model driven prototyping, using state transition diagrams. The tool interprets that to create the model. No code generation from the tool - it generates models. Events change the system, but may not be associated with a single object - thus the usage of state transition diagrams. No GUI for the front end, so things are loaded from a front end text file. They have an engine that generates models.

MODEL OT2004

OBJECT BOF
	NAME BOF Name
	ATTRIBUTES BOF Name String
	STATES proposed scheduled cancelled
	TRANSITION @new*Propose=proposed*Schedule=scheduled @any*Cancel=cancelled

OBJECT Room
	NAME Room Room
	ATTRIBUTES Name Name	String
	STATES available
	TRANSITION @new*Make Available=available available*Schedule=available

EVENT Propose
	ATTRIBUTES BOF BOF 	BOF Name String

EVENT Schedule
	ATTRIBUTES BOF	BOF	Room Room

EVENT Cancel
	ATTRIBUTES BOF	BOF

EVENT Make Available
	ATTRIBUTES Room	Room	Room Name String

Then you run the model generator (ed. - Java based - wouldn't Smalltalk or Lisp be way, way easier for this sort of thing?). You get a model that allows you to work with the state transitions as they have been defined. Hard to tell much at this point - needs more fleshing out.

This one comes from Keith Braithwaite of WDS Global and Steve Freeman of ThoughtWorks UK.

We are going to

• Seed some stories
• Break into groups and share stories
• Each group to discuss their stories and extract 3 anti-patterns
• Each group will present their anti-patterns
• Pick top 3, discuss

Dissenters should be tolerated as long as possible, but no longer:

• Some people take time to convert, give them time
• One "Professional Skeptic" can bring everything to a halt
• Special treatment for the squeaky wheel can cause resentment amongst the rest - possible on a non-XP team, virtually impossible on one

Proxy customers must remember their place

• Very few people saying they are doing XP are - most have a proxy customer, not a real one (Product Manager?)
• Knowing the solution domain well does not imply knowing the business domain well
• Having a proxy available when the real customer is not available can help
• Can blow up if they forget that they are not, in fact, the customer - end product will then answer the wrong question(s)

Must be prepared to pay the cost of fixing the mess

• Decent engineering is expensive to retro-fit
• Customers will not see any progress from this - they will start to think you are "wasting time". Unclear how to do this well. Only real solution is constant checking, or deal with catostrophes as they occur
• Probably won't like the extra discipline... they don't feel the pain

You need to be doing other good stuff beyond XP. There's not a lot to XP - it's light. What's not part of XP that is necessary?

• Small design up front doesn't hurt, and will definitely help. Not BDUF....
• Many people do not absorb the rigor required - especially if they have only "read the books" and not discussed it
• Version control - surprising number of teams don't
• Test/Code/Refactor is necessary but not sufficient. Have to have skill, it's not a silver bullet. There are process/interpersonal issues as well. You can run down refactoring rabbit holes, for instance....

Don't frighten the customer

• Most orgs adopting XP have other, non-XP projects. Don't be a full-time evangelist
• Over emphasizing it can be dangerous, and get you labelled as a "religious fanatic"

Stand up to the Customer

• Customers drive the project
• Doesn't mean they are always right or know what they always want
• Developers can be frightened of customer, and not question them, even when they "know" they are wrong
• This can end up delivering the wrong solution to the wrong problem

Step up to the customer role

• The "Real" customer is unavailable
• lack of feedback and direction increases risk - recall the "remember your place" in the proxy customer role
• Someone in that role is better than no one...

The exercise - come up with a few anti-patterns and proposed solutions. We came up with:

Create a Customer

• There is no customer
• Without a customer, rat holes abound
• Some projects - such as vendor products - lack a single definable customer

Get a new Bo peep

• Need a working team
• Coach leaves
• Lost Sheep after coach leaves

Hire experienced people

• The blind leading the blind
• They fall off the clock
• There's no substitute for an experienced coach

Other examples

Timely shutdown

• No customer - shut down the project (don't let marketing run wild
• Seeing the Forest and the trees - Lots of apparent chaos - step back, find the ball
• Right Rewards - Align incentives and development goals with reality and actual business goals

Personal Space

• 24 hour pair programming
• Not accomodating the individual
• Cabin fever - learning needs

Single Voice

• You have multiple customers
• You cannot serve two masters

Escape from refactoring

• Refactoring paralysis
• Stalled/No progress
• "The perfect is the enemy of the good enough"

Quarantine

• Small XP team in large company experiencing growth
• XP Team absorbed back into "mainstream" - XP practices lost
• Protect the team, keep it separate

Others I didn't quite get down - "Stealth XP" and "Explicit XP"

So we have a vote to determine the top three:

• Timely shutdown
• Personal Space
• See forest and trees

The voting results came back differently than at the Benelux conference - they all came back with issues surrounding customer relations, whereas we came back with technologist/team issues. Likely because this group is a technologist, but not necessarily doing XP. The Benelux conference was an explicitly XP Conference.

This is a case study presented by John daniels and Paul Dyson

What they are going to cover:

• Multiple teams - each team in one office? Not the topic
• Satellite Workers - most in one office, some remote workers. Not the topic exactly
• Dispersed team - Every team member is remote - this is what they are covering

Why do it?

• Cost (lower)
• Get people who do not want to travel/relocate
• Constrained by circumstances - (personal or business)

Case study, source: JD. Two FNL projects covered here. Both were part of a larger project

• Specialized Workflow engine, 2 people, fixed price, 5 months, server based (EJB), no UI
• Information management system with 4-6 people - T&M. Lot of interdependence between this part and others. Large EJB/J2EE project, 6 months

Case study - source: PD

• Integration of web services provision for internet platform. 4-5 people, fixed price, Java web services, no UI
• 4-5 people, 9 months, Java, multiple interfaces, migrated from office environment. Tried to develop a product from (1)

Working Environment
Needed:

• Full broadband (beware upload chokes!) - needed cable/DSL
• Phones plus conf calls
• Could use VOIP for one to one
• Powerful machines for team.
• Beware desktop sharing over net with large displays
• Install complete platform at each site - so need power at each site
• Wiki for sharing
• Version control system that works in this fashion
• NetMeeting for collaboration
• VNC or equivalent
• IM for chat/see who's around
• Security (physical and cyber) - in practice, ignored many of the customer requirements for physical security)
• Firewall
• IPSec encryption (same router at each site)
• Encrypted email (PGP plugin)
• if appropriate, encrypt HDs

Issues

• Tool support for this is currently very weak (very ad-hoc)
• Supporting multiple/varied desktops is very hard. Everyone ends up being an SA.

Interacting with the customer

• Initial face to face meeting (ongoing)
• cannot support regular XP model of an onsite customer
• More expectation mgmt needed - lack of shared experience in team
• More formal review periods
• Need to schedule customer time, as it is not going to happen otherwise
• Need more doc - without direct interaction, necessary
• Issues need to be resolved by phone/chat/wiki
• Customers had no access to the environment (VPN or servers)

• Customer had already donse some prototyping
• Customer had done extensive business analysis
• Jointly produced feature list
• Had access to their intranet and repository
• They were happy to use dispersed dev - saved desks/space

e2x

• Many onsite meetings for clarification
• 2 - 3 week iterations, delivery after each
• 1-2 days onsite to assist with integration at each step
• 1 week onsite to really integrate

This latter project was hard

General approach

• Evolutionary approach
• Short iterations
• Daily "stand up" meetings
• features vs. tasks - used tools like the Wiki and spreadsheets to manage the difference

One thing learned - used Wiki as a "virtual wall" of cards for the project. Very difficult to enforce without discipline. Worked well, but the team needed to think about it. The actual development process was not a lot different from normal - other than the need for on site delivery and integration - in a full on site job, would have been more natural.

Designing the System
Needed to do early architecture/design work in up front face to face meetings. Worked better face to face, later on used shared desktop with virtual whiteboards. Did this in UML, used Rose (somewhat). The process was API driven (from the EJBs). Design doc was produced after the fact, not during or up front. Revisiting the design decisions were more important than in a "normal" XP process, as there is less lunch/coffee (etc) side conversations. Needed to make up for that lack. Ran up against poor tool support for dispersed diagramming.

Team Organization
mixed pairing with "buddying" - work alone, but check in with buddy on a regular basis. When pairing this way, agree on how work was to be done and split it up. Work as a pair until complexity was understood, then just go off and do it. One common split - tests vs. implementation. Most tasks were paired, there was the odd singleton task on the e2x project. In response to a question, code review and code quality takes extra work.

Programming Technology

• Eclipse

• Eclipse and Tortoise clients
• Server running on spare PC (Server hosting)
• e2x later switched to the tool they were building (Cyclex)
• Pair programming with NetMeeting
• Slight delay over wire if you are not the driver (mostly ok)
• re-synch to version control to switch driver
• Mostly worked w/o problems!
• Varying degrees of continuous integration as a result (IMHO, not a lot different from normal process issues)

• Process for programming tasks
  
• Sketch the ifc
• Code the tests
• Run new tests
• Code the implementation
• Run new tests
• Iterate until pass
• Run all tests until integrated
• Check in
• test focused rather than simply test driven
• Updated user abd design doc before each software release

Project 2 FNL

• Used customer repository
• No Eclipse integration
• Couldn't use NetMeeting while connected to their repository - made pairing very tedious
• Pairing over NetMeeting via ADSL
• Once VPN worked, easy
• audio and desktop sharing worked well over VPN

Project e2x

• Who's got the monkey?
• Used an actual "monkey" toy in the office, what to do remotely?
• Use IM (did not work as well)
• Lack of "overheard" conversations
• Interruptions are worse than when co-located (other phones, door, etc)
• Latency makes swap over a problem
• Poor support in CVS
• Supported in Cyclex

What about Testing?

• General
• Focus on functional tests - are unit tests still important? They think less so
• Used JUnit
• Automated one click testing critical
• FNL
• When paiting, both developers had to get all tests to pass on their machines before it was agreed to be done - the "it works on my machine" problem

General Advice

• Shared understanding of the tasks is crucial
• e2x: Does work with people you don't know. Works better with people you do know
• FNL: Only employed people that they knew already
• Minimized start up time
• Minimized cultural/personal diffs
• Face to face - especially with customer - is still crucial!
• Important to establish working etiquette as you go along
• Allow time for setting up the infrastructure (VPNs, databases, etc)
• Test focused
• Maximum team size limit? They have done 5-6

Discussion session

• One thing that comes up is that all interaction has to be more considered - and somewhat more formal - than in an office environment. John Daniels: This form of pairing is actually more productive (admittdely, anecdotal).
• There are times and tasks where people work more efficiently alone. Remote development with buddying allows for that

This session is going to talk about:

• What an XP story is
• How stories differ from Use Cases
• Where analysis fits in the XP Process

On site customer - proxy for all the stakeholders (ed. - politics). The on site customer is used instead of documentation.

Q - What about maintenance phase, which is 80%? What about doc for that?
XP - XP is weak in this area.

On site customer needs to know the system requirements, Communicates context, required outcomes. Prioritizes work based on business value. Available to answer questions

Stories
Stories should be of a size where you can build a few of them in an iteration. Stories are time boxed by definition, and should be between 1 and 5 "ideal" programming weeks.

Q - What about projects that may well span much more time than that?
A - XP is not a silver bullet - not all problems can be solved via stories").

Story format is not important. Has a title, concise problem statement, sketches of screen layout, etc.). Now the group is discussing how you fit in things like refactoring (etc). Some things aren't part of the explicit customer stories, but are part of their implicit desire for a maintainable, working system. Side note on my part - I can see an RSS feed for stories being a very nice fit :)

Acronym Invest

• I Independent
• N Negotiable
• V Valuable
• E Estimable
• S Small
• T Testable

Unit tests are not enough, we need acceptance tests as well - "When I do tis action, I expect this result". Ideally, test suite should be automated. The tests help you collaborate with the customer and iterate towards "what they meant" as opposed to "what you did". This is easier said than done, IMHO.

So - why stories on index cards? Because you can't overdo it - can't fit much text on a card. Easy to get everyone involved.

Pitfalls

• System requirements may be too large to fit in customer's head
• Customer does not have time to do their end
• Customer is not on site
• Customer blind spots (missing tests)
• Losing parts of stories
• Customer team, many voices
• If customer spends "too much" time with the team, may lose touch with business stakeholders

Shoring up - Multiple customer teams? Story repositories?

Exercise
We took a simple order entry (CRUD) system. Split into roles (customer, QA, developers) and develop stories. Then, passed stories along to next table to look. As it turns out, the stories we received were much more complete than the ones we sent along - we were very incomplete. basically, we did not include enough story detail, and mostly omitted acceptance tests. The results were mixed - two groups created stories with tests, two groups (like ours) created decent stories and tests (within the time constraints). Very interesting exercise, opened my eyes on this area.

Immo H%FCneke was kind enough to share his notes from Ivar's talk - he didn't miss the beginning. His notes:

An evening with Ivar Jacobson

Bruce Anderson introduced Ivar as someone very well known in the industry - best known for the introduction of Use Cases.

Q: Do you think that the move from text-based to more highly structured use cases is a step forwards or backwards?
A: It's a step forwards! We need structure in requirements. Anything else sends you to sleep in two hours. But I'm cautious not to formalise more than necessarily. It's easy to formalise, but very hard to get the right formalism. With experience of Vienna Development Method (VDM) and other formalisms, I believe that "some structure" is appropriate.
Q: Is Use Cases the universal method for expressing functional requirements or is there anything else?
A: There are things better expressed using mathematical formulae, spreadsheets or anything else - but such expressions should probably be attached to a use case.
Q: What about something like a video-game, which is very state-dependent?
A: Probably just one or two use cases there - "play the game". The radio in a Volvo car was described button by button in the manual: I could never learn how to work it. It would be nice to see appliance manuals structured along Use Case lines.
Q: Would such a use case be structured along the lines of what actions the user wanted to do in the game, e.g. "kill adversary"?
A: People use state charts, activity diagrams, screenshots etc. to describe the use-case. The documentation should be anchored in something concrete, not floating in semantic emptiness. Use an object model (we call it analysis). The analysis model is more precisely expressed than the use case model. It uses activity diagrams, swim lanes etc. to express the realisation of each use case more precisely.
Q: What about XP then, which just uses stories and goes straight to code?
A: That's a lightweight process, which can be used to generate rapid prototypes. Lightweight use cases are appropriate for a lightweight process.
Q: Sticking with requirements, how do you deal with the distinction between functional and other requirements? Is this a good categorisation?
A: In most cases, this distinction is useful. Most of the non-functional requirements are specific to one use-case (e.g. performance - making a telephone call has one performance requirement, hanging up a call has another).
Q: But what about qualities that have to apply to the whole system?
A: RUP puts these in a document called supplemental requirements. But security (an infrastructure requirement) is well accommodated within the Use Case structure. Aspect-oriented development has become quite popular for infrastructure requirements.
Q: Why has aspect-oriented become important?
A: Separation of concerns. Security can be dealt with separately, without even talking about specific applications. This can be traced to code and tested separately from the rest of the system. Every new feature (e.g. follow-me service, directory enquiry) can be specified separately but has to be integrated into existing code that handles telephone calls. Result: scattering and entangling. This is the nature of the systems that we have lived with for 20-30 years. Aspect-oriented approaches allow us to escape from these impacts.
Q: But what has this got to do with use cases?
A: A quite simple but powerful mechanism, which allows us to keep the use cases separate. In the future, we will be able to develop, deploy and test each use case in isolation. They can be composed to build systems rapidly. It was a huge step to move from structured to object-oriented languages, but this switch to aspect-oriented is just a refinement.
Q: (JD) Bruce, did you understand that answer?
A: Yes!
JD: then it's just me!
Q: Before you started work for Rational, you were successfully promoting your own method, Objectory. Is RUP just Objectory renamed, as you are quoted as saying?
A: I have never said that.
Q: Well, you must have had to make compromises with your colleagues when leading the RUP development?
A: No. But Objectory v. 3.8 was really RUP.
Q: Was anything lost in the process?
A: Yes, a few things - I was never very happy with the way we describe architecture in RUP. It is correct, but probably unnecessarily complicated. Another thing I miss is analysis - we do analysis in a diluted way. Today we can not have a process that isn't supported by a tool. The process is said to have been adapted to the limitations of the tools, but perhaps analysis has been removed because the tools didn't support it. For example, Objectory supports multi-modelling, while ROSE doesn't. There still are people working with the old Objectory tool.
There is a perceived distinction between Objectory and RUP. Business processes including the software development process itself are modelled in Objectory. When I first began to develop Objectory at Ericsson, they had a good process for component-based development. But all we could give programmers was templates - there was no guidance about creating good sequence diagrams, state charts, good components etc. So this was where we concentrated in Objectory. We ignored project management. Just to give you an idea why Objectory was well-liked: it was the only tool that gave you help with these aspects. The single user licence was $22K! Yet we sold over 300 copies. The most expensive copy sold was $1M.
Q: RUP doesn't support architecture very well, does it?
A: The way Objectory got developed, the system is modelled through seven or so models - use case model, analysis model etc. Even the code is one model. There was also a test model at one time. Today we talk about viewpoints and perspectives. Models are easier to comprehend. Architecture should be just the use of the models. This should be fixed.
Q: So should we have architectural views of each of the models?
A: Yes, to present the essential core of those models. I don't like the term "executable architecture", I prefer to think of it as version 0.1 of the system.
Q: Let's talk about MDA, another "hot" topic. Some people look on the MDA models as just programs in a very high level language. What's your view on those models in MDA?
A: Model driven development is usually seen as a positive idea. MDA is more specific: it requires you to build a PIM (which is analogous to the analysis model in Objectory). It is supposed to be expressed in an executable language. I don't believe it is ready today to develop production-quality code. One day we will get there - the platform-specific extensions still need to be developed. Anyone waiting for MDA to be delivered before embarking on a new development is playing a high risk game.
Q: Looking back over your career, is there anything you would prefer to be remembered for than Use Cases?
A: I never thought that Use Cases would be so important - I was quite surprised by their success. I think the most important thing I did was to introduce component-based development in Ericsson. We had sequence and collaboration diagrams, state charts on components. This helped to make Ericsson as successful as it now is.
Q: Which of your innovations has earned you the most money?
A: Not an innovation, but perhaps a mis-translation: Use Case was originally Usage Case in Swedish!
Q: Software Engineering Professionalism: XP and agile approaches in general seem to emphasise the art/craft aspect of software development rather than engineering. Is this a step backwards?
A: Large groups of people have always viewed software as a craft - actually the proportion that views it as engineering is growing steadily. Languages go in cycles - Smalltalk is coming back into fashion. Tools are getting more powerful because we understand software engineering better. All my life I have worked on understanding how to develop software. I have worked with models and process to simplify it. It is engineering more than an art form. You can't be trained to be artistic, but I refuse to believe that only the select few can be really good at software development.
Q: Another quote is "XP doesn't help you to grow an organisation". What did you mean by that?
A: I can't remember saying this. In the context of the quote though, it makes sense. I believe that there are lots of good things in extreme programming. It has put the finger on agility, which was not explicitly addressed by my processes. However, the whole purpose of Objectory was to codify knowledge of how to create good software, with the aim of making the process more reliable and faster. Knowledge has to be applied, yet RUP by itself doesn't apply anything. You not only have to know something, you also have to be smart in applying it. I would use something like XP for every new product I worked on, because you have to start small. There isn't anything in XP that people haven't been using for 30 years, but it has put them together in a very nice way. As soon as a product is successful, we have to grow beyond XP processes in order to prevent loss of knowledge as people move away to other projects. You can use RUP in a very lightweight manner to support an agile process and then grow it. For example, my daughter and I recently developed a rule-based product based on intelligent agents. She had no need to use RUP, but did so anyway, and it is growing with the needs of the company now that the product is becoming successful. A shortcoming of XP is that knowledge is not explicit, it stays in people's heads. RUP makes knowledge so explicit that it can be automated using rules - which is what the product I mentioned does.
Q: Is RUP heavyweight then?
A: You can use as little or as much as you like.
Q: What do you regret not doing differently?
A: At OOPSLA, I got the same question. There are a couple of things. Dave Thomas is a very good friend. He visited me in '98 in Sweden. He had looked at Objectory and felt very positive about it. He said I should write a very thin book (125 pages at most) about Use Cases. He also urged me to let him develop a tool for it for $100K. But with my Ericsson background, I thought that writing such a thin "stupid" book and developing such a small "stupid" tool was not something I would ever do. In fact it could have been a lot of fun.
Q: What's on the cards for the second half of the Jacobson Career?
A: If you look at software and automation in general today, how has it advanced in 100 years? Ericsson's first switch in '23 was built out of relays, which was the dominant technology from '00 to '50. Joining Ericsson, I felt that we were nearing the top of the S curve. Software was the answer - it made it easy to add new features to switches. However, we now are reaching the limitations of software. Every piece of equipment you now buy comes loaded with software, most of which we cannot use because some idiot designed the user interface (passive software). We need to move towards active software - which can intuit what you are trying to do and help you to achieve it. Software that can help you to improve the way you do things and shorten the path to success. Active software is coming into all kinds of applications already and is going to grow.