I graduated in Cybernetics and Control Engineering in 1999, escaping from university with virtually no knowledge of computer technology.

Got a job, picked up some shallow skills. Taught myself HTML, JavaScript, then Java.

Spent 3 years as the main developer on a CRM solution. Lots of MovingGoalPosts from the customer. Never enough time, and lots of contractors turned out to be CowboyCoder''''''s. 

Moved to Oz, almost up to a year as Web Master (whatever that is) in a Queensland Government authority. Currently trying to get a CMS in place.

Lessons learnt;
*I can affirm that the customers need to feel that they participate too. I like the slant that XP takes on this, and especially the GoalDonor/GoldOwner duality. 
*CollectiveCodeOwnership is correct, but fails to emphasize that the project has members from the customer base - we didn't appreciate this fully, they got upset at the lack of communication and punished us by overly-criticizing small (usually GUI styling) problems with working code. The problem actually lay with the customer's management structure, but we paid the price for poor project-team planning and communication.
* there are several functions that need to be built into an application with long sessions and/or deep functionality (eg CRM solution, as opposed to an email provider). These may seem obvious, but were not when we started, and were hard to put into a web app;
**session-tracking - so you know who is using the application, and what they have done.
**the CommandPattern - so you can undo/redo. It also offers a way to tell a user what they have just done, and the effects that the action has had (not all users understand what they are doing).
**messaging - so you can reach a user who is in mid-session, eg to tell them that the server is coming down in 10 seconds,9,8,.....
**caching - so that semi-static objects can be refreshed as needed. Two different uses:
***Avoiding once-only loads. For example, once you have found that a user is doing something they shouldn't, you can restrict their security access and have it take effect immediately. Our app loaded a user's security access once, when they logged on, and we could not kick them off or restrict access mid-session.
***Infrequently changing dynamic content. In a web app, many dynamic pages only change infrequently - lists of documents, and calendars are the obvious ones - and these should be generated when the underlying data changes, not on every request.
**set operations - once the customers can perform an action on one thing (eg change one contact's product data), they will want to be able to do it to a whole set of them (eg a list of contacts who have cancelled their subscriptions). Although it is not XP to anticipate, I think that this is fundamental enough to be built into every system asap. 
**set selection - follows from set operations - to operate on a set, you need to be able to find it, and save it and/or the criteria that found it.
**flexible data visualization - this follows from set operations - most apps show one thing at a time for CRUD, but sets need to be able to show all the bits that fit into the set, and the things that stick out (eg. yes, these 2 contacts have cancelled, but they also cancelled then re-joined last month, so maybe phone them to check). Also makes the users happy - not everyone can interpret a particular representation effectively.

I have contributed (not necessarily well - this list is for me to track my own meanderings) to:
*GoalFailureInProgramming
*NiccoloMachiavelli
*DontDistinguishBetweenClassesAndInterfaces
*BigModelsAreUseless
*DataCentricThinking

OzLanguage
FlowBasedProgramming
----
CategoryHomePage