If you have downloaded a recent development build, you'll want to visit the site and grab the latest. There was an odd bug that arose when I added some code to check for a possibly running version - detecting one results in the auto-save feature being turned off. Unfortunately, I had the auto-save being turned off no matter how the check went.
This story left me rolling on the floor laughing. Either Gosling had no idea that the elisp in Emacs was part of something larger, or he's just completely clueless. Possibly both. Here's a quote from the page:
The Jackpot team is engaging in experiments using the open source NetBeansTM platform. NetBeans, the product of a small but widely-known company in Prague, the Czech Republic, is a modular, extensible IDE, written in the Java language, that has been in open source since June of 2000. The SunTM ONE Studio (formerly ForteTM for JavaTM) product line is based on NetBeans. By taking their experiments out of the lab and into the open-source developer community for real-world feedback, the team is opening the project to the wealth of talent in the open source community. "There have been a lot of good ideas and interesting approaches that haven't been reflected in the commercially available tools, particularly the IDE interface," says Michael Van de Vanter. "We're experimenting with plug-compatible tools on the NetBeans platform. By getting feedback from the open source community, we will further refine our prototypes."Not available in commercial tools? Apparently, neither Gosling nor any of his team have ever seen a Smalltalk or Lisp implementation. Or if they did, they didn't understand it. Or I suppose they could just be making wild assertions that they are boldly going where no one has gone before, assuming no one will know the difference. That would make them lying weasels, of course, but hey - that's just my opinion.
Smalltalkers can now more easily connect thanks to the efforts of Janko Mivsek, Peter Hatch, and Rado Hodicak. This was posted to comp.lang.smalltalk this morning:
I'm glad to announce that a Smaltalk IRC Network is born. As you probably know, an IRC server run by Pete Hatch exist for a year or more already. To improve robustness and availability of IRC regardless of any internet related troubles, we decided to add two more servers and connect all of them together in IRC network. So, now you can connect to those three servers:This really great - a lot of the BottomFeeder work was helped out via the IRC - it's been the primary means of communication between Dave Murphy and I.irc.parcplace.net (US, run by Pete Hatch, nickname pete) irc.4096.sk (Slovakia, run by Rado Hodicak, nickname rh) irc.eranova.si (Slovenia, run by Janko Mivsek, nickname Misolin)After you connect to one of those servers, join a general channel #smalltalk . You can open your own channel like #squeak, or a channel for your project, for your group, etc etc .. And what is IRC chat good for?
If someone likes to join the net with his own server, he is welcomed. And specially squeakers are very welcomed too :) It is my desire to join all Smalltalkers to communicate together and being on the same IRC net, even on separate channels, is definitively a step towards that goal. So all of you are invited to join :) Janko
- staying in touch with Smalltalkers around the world
- feel of community
- fresh news, rumors, stories are heard on IRC an nowhere else ;)
- real time "help desk" for your problems
- good communication media for your Smalltalk group
- remote XP like work
- and many more.
Boris Popov has posted some interesting Logo possibilities. Personally, I like this:
In September, Sam Shuster put out some information on the changes coming to the VW GUI with the upcoming 7.1 release of VisualWorks - the singleton UI process is gone, replaced by a more flexible system that will allow per window (or per application, or any other combination) processes. To get the lowdown, follow this link to the September Smalltalk Digest.
Readers of my blog will know that I'm skeptical (to say the least of the so called analysts - see here, and here, and here, and finally, here for my last round of rants on this subject. Still, many large companies seem to take what these people say as gospel, which means that this report on web services from the Meta Group will have a lot of influence:
According to META Group, more than 90% of large organizations will utilize host access products that externalize legacy applications via Web services by 2007 "We expect host access products to continue playing an important role for large organisations externalising legacy applications," said Mark Vanston, programme director with META Group's Enterprise Data Centre Strategies service. "Web-to-Host access solutions can reduce the cost of legacy integration, enabling organisations to leverage existing assets and capitalise on new IT opportunities"Better go get the SOAP out...
I saw this usage report online, and it made sense. The approach those guys are taking seems much simpler than a SOAP basd approach:
At my company we are using a REST-based interface to allow the import and export of data to and from our trading system. We considered using SOAP, but felt that it would create an unnecessary extra layer of complexity without offering any benefits over a REST architecture. In fact SOAP's RPC approach seems to have many short comings versus the Representational State Transfer approachWith VW, this all ought to be pretty straightforward. You create servlets using Web Toolkit, and deal with the inbound and outbound XML using the XML support. A whole lot simpler than SOAP, and it's something that could be grown very incrementally.
The Call For Participation is out. Next year's show will be held in Toronto, Canada July 14-16. Hope to see you there!
Croquet was built to answer a simple question. If we were to create a new operating system and user interface knowing what we know today, how far could we go. What kinds of decisions would we make that we might have been unable to even consider 20 or 30 years ago, when the current set of operating systems were first created. The landscape of possibilities has evolved tremendously in the last few years. Without a doubt, we can consider Moore's law and the Internet as the two primary forces that are colliding like tectonic plates to create an enormous mountain range of possibilities. Since every existing OS was created when the world around it was still quite flat, they were not designed to truly take advantage of the heights that we are now able to scale. What is perhaps most remarkable about this particular question is that in answering it, we find that we are revisiting much of the work that was done in the early sixties and seventies that ultimately led to the current successful architectures. One could say that that in reality, this question was asked long ago, and the strength of the answer has successfully carried us for a quarter century. On the other hand, the current environments are really just the thin veneer over what even long ago were seriously outmoded approaches to development and design. Most of the really good fundamental ideas that people had were left on the cutting room floor.Go read the whole thing - it's well worth the time. They are using Squeak as the basis.
There were some issues with the arguments I was passing in the urls - specifically, they had spaces in them. This didn't cause any problems for newer revs of IE or Netscape, but older browsers had problems. I should have that licked; please send me email if you spot something.
I read this story with trepidation. Apparently, the 8-12 year old set wants a cell phone - and the Wired story says this:
If a child in this age group doesn't already own a cell phone -- 21 percent of them do, according to research by SpectraCom -- he or she is likely part of the great majority pestering mom and dad for oneFortunately, my daughter still seems to like board games and Christmas decorations and Barbie more than this stuff. Whew!
Here's an acronym I ran across awhile ago and ignored, but looked into a bit today: REST: REpresentational State Transfer The idea seems to be, if you can do an HTTP GET and get back an XML document for parsing, that's REST. How you know what you are going to get back? Anybody's guess, I suppose. Anyway, here's the story
Boy, I remember this kind of contradiction at PPD back in 1995-1996. Lots of fun for everyone. All the people managing this merger must really like the article's title:
Sun has recently posted a list of new proposed features for Java 1.5. These include:It's as if the Sun guys almost get it, but not quite... Closures? Nahh, that would be useful, can't have that for the unwashed masses, can we? The Wiki Ref above actually makes some interesting proposals; on the other hand, people wanting such things could just use Smalltalk and be productive now. Can't have that either, I suppose; gotta follow the herd wherever it goes. At this pace, Java might conceivably be as usable as Smalltalk in about, oh, maybe 20-30 years. In th emeantime, the suckage continues....
Useful links: The JSR document describing these proposals in more detail and the discussion on The Server Side. It's interesting to note how these changes are mostly cosmetic alterations to syntax rather than deeper semantic changes such as adding blocks. There's an interesting wiki page I started a while back that offers some interesting proposals that would really shake up Java.
- A syntax for defining enumerated types. This syntax provides linguistic support for the Typesafe Enumeration pattern.
- An automatic conversion from primitive types to their corresponding reference type wrappers. This conversion facilitates the integration of generics into the language, and reduces inessential clutter.
- Enhanced for loops allow convenient iteration over collections, without the need for an explicitly defined iterator. This reduces the need for boilerplate iteration code and the corresponding opportunities for errors.
- Static import. A mechanism to allow the use of unqualified constants.
In October, Alan Knight traveled to Erfurt, Germany for Net Object Days. You can see his trip report here
See the whole story here. My first take on this - it moves IBM away from the whole Agile Development Camp - Rational in general, and the RUP are not agile proponents by any stretch of the imagination. It will be interesting to see how this one plays out. This is also interesting for other reasons - I'm of the opinion that Sun is doomed, as they are being squeezed on the commodity end by Microsoft and Dell - meanwhile, IBM is hitting them hard on the enterprise side. My guess is that IBM will eventually by the rights to Java and Open Source it. Right or wrong, I think it's going to be an interesting next couple of years in the IT business.
The Times story (free registration required) - has some interesting comments about Alan Kay and Smalltalk:
Dr. Kay and a few PARC colleagues, notably Dan Ingalls and Adele Goldberg, also developed Smalltalk, an influential programming language that uses blocks of code, known as objects, that are put together, like the cells that make up the human body, to build applications.That's a nice quote from the mainstream media on Smalltalk!
First, bear in mind that my notes are not comprehensive - I didn't see all the talks, or even most of them. However, here are the permanent links for my blog entries on the show: Kent's opening talk Brief show notes, first day Scott Ambler - Agile Data, Agile Databases Kent's Keynote, XP Brazil Rob Mee on XP coaching Lowell Lindstrom - XP for the customer My thoughts on the show
UPDATE - I made the links friendlier for ancient browsers.
I gave my talk on XP in Smalltalk, and why I think it's better that way. You can get the presentation here. I had a good audience, and interestingly, a good number of non-Smalltalkers. All of the attendees received an NC CD, and after my talk, I had a number of people come up to ask questions. The thing I showed them - maybe I should have done this in the presentation - was to bring up the Web Toolkit ToyzInc demo, and walk through it. Then put a halt in a page, and watch the jaws drop! Yes, tools like Eclipse are getting better, but JSP coding isn't nearly this productive or fun. Anyway, the show itself was a lot of fun. I actually got to attend this show, instead of pulling booth duty (my typical fate at these things). It was a lot more fun to listen to the presentations. Once nice thing was that translation was provided - not just English to Portuguese, but also the reverse - so I could participate in events held in Portuguese - very nice. The XP hour on Thursday was especially nice that way. Funny thing, or at least ironic - here I studied Spanish for ten years, and the first country I visit in South America speaks Potuguese. I ran into three simply wonderful people from Paraguay who also did not speak Potuguese, and for whom English was their second tongue. I spent a couple of pleasant lunches conversing with them.. oh well. The folks from Object Magazine (Brazil were also very nice - Thanks Daniela for being so patient with my Spanish and (very halting) French. Daniela was kind enough to ask me to write an article for their magazine, and her editor asked to interview all of the invited speakers via email. I am pleased and humbled to be included with such a group of XP luminaries. Daniela (and a few other people) encouraged me to write a book - gosh, that sounds like real work. I'm tickled, and we'll see if I have that much ambition. The conference ended in a panel discussion on the future of XP - Kent Beck, Flavio, Scott Ambler, Lowell Lindstrom, Rob Mee - and Klaus Wuestefeld (an organizer and emcee, as well as XP expert) surprised me by asking me to participate in the panel. I took this as quite an honor! It was interesting - lots of good audience questions, including one on the future of Smalltalk. I related Cincom Smalltalk's annual 10% year on year customer increases, and that there are more Smalltalk vendors now than there were back in 1993 (Object-Arts, Object-Connect). This led to an interesting question - and later conversation - with Rob Mee. He has been working on a project with an old (conservative) bank in Germany, where they brought in all Open Source products to solve a problem - see my post on his talk for some notes. Well, that's a hard one. On the other hand, some of those OS things - a mock object framework (not needed in Smalltalk), JUnit (ships with VW), Eclipse (cool, but not as powerful as VW) simply aren't, IMHO, that relevant. Others, like Tomcat, are. On the other hand, the VW server frameworks scale quite nicely. The larger point is that there are scads of Open Source components for Java, and doesn't that swamp Smalltalk's ability to compete? Well, there are two answers to that
- First, ask any of the XP luminaries what they would rather code in. After you here Smalltalk from almost all of them, draw your own conclusions
- Second, The productivity gains in Smalltalk - 3x according to the SPR numbers - will still yield an earlier delivery
Lowell Lindstrom of OMA spoke on a very interesting topic, and one that seemingly gets overlooked a lot - the customer side of XP - what do they get out of XP, and why do they care?
The Customer side of XPWhat is our (developer's) ability to predict what the customer wants? not so good What is the customer's ability to specify what they really want? not so good So OMA started teaching XP classes a few years ago, and gradually came to the conclusion that teaching developers about XP wasn't enough. They had to talk to the customers as well.
Metaphor - Lowell related a story about his sister learning to drive. Lowell was ten, riding in the car with his family, typical vacation. He and his brother fought, suddenly Dad tells sister (close to home) that she can drive Instant quiet - the brothers weren't sure they were safe (audience laughs). Only problem happened on last turn home. Sister doesn't make the turn correctly - doesn't cut wheel enough, heads for a fire hydrant. So Dad grabs wheel, pulls it, and yells a lot. So what does this mean to us? Steering is difficult when starting out. It's nice to have someone to help you out. In XP, the customer is steering.
So what about Lowell? He started as a developer working with Bob Martin (Uncle Bob), who was then heavily involved in the C++ Report and OO community. Started Gravitating towards the customer point of view early - programming was fun, but not his passion. Moved into customer relations, product marketing, and Q/A.
So when OMA started teaching XP classes, they ran into a common issue - trust between customers and programmers was typically not high (on either side). Programmers generally didn't respect the customer, the customer did not trust the programmers enough to tell them what they really wanted. Solution - Lowell started teaching XP for Customers First class, adapted slides from the standard XP class. This was fine until they came to this:
- Heard Ron and Kent talking about XP
- Heard XP as a developer side thing, without enough customer side
- Thought, how does XP impact sales, marketing, management (etc)?Why are we here? Because we like to programhmm. This required some dancing and adpatation. So why are customers here? Lowell has answers, but is still looking for a better quick summary. Customer's dilemma
So again - Customer's dilemma Audience feedback to this - what does the customer want?
- Market is changing fast
- The business is becoming more and more reliant on software (which is hard to get)
- There is still a shortage of skilled programmers
- There are lots (too many, almost) internal and external customers
- There is a constant need to make very difficult choices about focusing limited resourcesMake work easier Have more people use the product(s) Bring in profit Improve efficiency Improve reliability and repeatability of delivery to customers Have time for personal stuff Actually get the products that the customer wanted Better Time ManagementAgain - Customer's dilemma They want the same thing as developers - they want to execute the business as well, as much, with as little stress, and as much success, as is possible.
KISSSo they derived a Customer's Bill of Rights Customers have a right to:There is, of course, a matching Developer's Bill of Rights
- An overall plan - what can be done at what cost
- Get the most possible value out of every programming week
- See progress in a running system proven to work by repeatable tests you specify
- Change your mind, substitute in functionality, change priorities without paying exhorbitant costs
- Be informed of schedule changes in time to choose how to reduce scope to restore the original date.
- Cancel at any time and be left with a useful, working system reflecting investment to dateLowell drew a picture here, showing the overlap between the developers, customers, and stakeholders. The stakeholders - end customers, marketing, sales, management, media, testers, etc. - are often pretty remote, but still must be taken into account Key concept - it's a Whole Team Customer Team practices
- Know what is needed with clear priorities
- Produce quality work at all times
- As for and receive help from peers, superiors, customer
- Accept responsibility instead of having it handed to you
Not necessarily comprehensive - but key if you want a well fuctioning customer team
On site customer Business strategy alignment XP Planning Managing High level requirements Acceptance tests Stakeholder feedback Small releases Conflict resolution Metaphor Contract structure
Managing scope Lowell drew a diagram with a set of boxes in it. The boxes are customer requirements to be delivered. Question - how many projects have completed exactly as they were specified? No hands go up. Ok, some do more, most do less, some deliver a less pluss some things not planned for. What's important? That the dividing line is far enough down that the customer perceives value - and has the acceptance tests that prove it. If we can deliver that, then the customer will probably be mostly happy
Rob gave a talk this afternoon on XP and coaching. My take on the XP coach is that it sounds a lot like a baseball manager - the job isn't to play baseball, but to make the other guys play baseball to the best of their abilities. now, like any metaphor, this one doesn't hold completely - while both jobs can be seen as transient (just look at how long the typical baseball manager lasts!), they aren't really the same. The coach is looking to train the team and go - the manager is really not hoping to work himself out of a job. In any event, Rob did a better job of conveying this than my notes indicate. It was a very interactive session, with a lot of feedback solicited from the audience. Here are the notes:
Rob MeeXP and Coaching What is it - if XP is self organizing, why do we need a coach?
i.e., much like a sports team coach Attributes of a good coach?
- Someone who has done it before
- Observing (everything)
- enforcing discipline
- Course correction
- Participating in all team practices
- keeping the balance
Questions: What about business domain knowledge?
- technically Competent
- Likes to share power and responsibilityYou won't come in with it anyway. Will have to learnWhat about coaching the customer team?(Lowell)Could be a separate person. Just as we need competent programmers, we need competent customerWhat is the most challenging of these skills for you?difficult to answer in three minutesCoach is a separate role from programmer - does he program?Yes, participates and pairs (hopefully with everyone)
Tips, Techniques, Patterns How to win over a reluctant team (individual)?Promise to go away after a fixed time Ask for temporary cooperation They can do it their way when you leavegood cop/bad cop (Rob, Kent - audience laughs) The integrator bunny Use a fun or provocative token for integration. breaks the ice. Team building Used a bunny - too small, got lost. Then used bunny ears (wearable) Pattern - Ronaldo (soccer) work is not everything The coach needs to make sure that the team makes non-work time part of the culture Live your life normally, and do your job better Relax, get away from work, get refreshed Strategic Retreat As soon as you start coaching, you are on your way out
Experiences - question on failures references Kent's project cancellation story from yesterday Quote - XP is more suited to party people than other processes (Kent) - as a coach, it's important not to get sucked into the personality conflicts of the staff Experience - XP at a Silicon Valley startup, $25M funding large, ambitious browser based system Currently about 3000 unit tests hundreds of acceptance tests Flexibility
- Start delegating
- lead meetings less often
- Stop giving tech advice
- Make fewer decisions
- removed WebLogic EJB 3 weeks before going live
- Planning module - 4 dim rotating model, designed to handle 3 million nodes -- changed to handle 350 million in 3 weeksHow to replace the coach?
Experience - XP in Germany
- start finding possibilities early
- intensive mentoring
- handing over of responsibility
- encourage XP community contribution (articles, talks, etc.)
Fired all staff, waited a week, hired 12 back 1st meeting - mgrs, 12 staff - We need you to teach us XP Results
- 100 year old insurance company
- 4 yrs
- 70 developers
- how much money did you say?
- nothing delivered
Tests Customer tests - Fit Unit tests - independent - no db contact, no 'container' (Tomcat) contact Why did it work?
- initial fear and dismay
- most doubtful - cried, even - became biggest champion
- team evolved into best estimators ever seen
- 8 weeks to a deployable system
who to become new coach?
- realistic goals
- one week iterations
- OS packages (over 10)
- Sane working conditions
Answer - coalition of all three Audience questions - how long to get there?
- one diplomatic, flexible, communicative
- another refactorer, aggressive
- third - technically brillianttypically 2-3 months if team has no XP knowledge With some background, small team - could be 3-4 weeksKent - principle behind XP is one of creating social networks, not hierarchies Coaching is not about "power and glory" Job one - make the coach go away Job two - create a replacement
delivered by Kent Beck. He had an interesting talk, and got a lot of feedback from the audience. My notes:
Keynote - Kent BeckThe Spirit of Extreme Programming Asked the audience for some expectations - questions related to topic of talk
How did XP get started? (Creation Myth)
- How do you deal with the question - How dare you challenge the conventional wisdon?
- How do you handle personality issues?
- Do you always find an appropriate system metaphor?
- How often are clients really involved in the process?
- How do you convince an organization to use XP?
- Pete McBreen - Software Craftsmanship - square with XP
- From a client perspective - what is the value of XP?
- how to iterations work with project manager schedules?
Always been a programmer, father was a programmer. Always immersed. Was in the Smalltalk world, where it's easy to learn about programming. Technical expertise is just not enough - projects mostly fail for political reasons. Wanted to expand his viw beyond the programming to the whole context of programming. Question - what is the least I can do (besides programming) and still succeed? Only once - 1994 - got in at the start of a project. typically gets in after deadline, when everyone hates each other, and when the money is gone. This project is where SUnit, lots of testing, and frequent refactoring were born. It was a typical mainframe to mid-range project. After 4 months, much progress - but management liked it so well, that they explained the actual goal, as they say it - get the calculation engine running on the mainframe. So goals are important - but they change Next - brought into Chrysler for the payroll project. The goal was to fix the performance problems. Asked - where are the tests, so I don't break anything? Answer - we don't get correct answers yet. Said - I can make it run fast, so long as you don't care what the answers are. So, half the team left within 3 days, contracters were kicked out. IT chief asks for answers:
picked option 3, so long as Kent was in charge. He objected, as he said he was not a project lead. CEO convinced Kent with large sums of cash. inspiration - a combination of preparation and panic Now had plenty of panic. Interviewed entire staff so as to get to know them better. Came up with iterations (3 weeks), stories (to flesh out iteration goals) with first person. As things progressed, came up with acceptance tests to validate. Then came up with Unit tests as a developer task to help get to acceptance test Kent: I was just making this (expletive deleted) up Open workspace, people sitting together, continuous integration, unit testing - it all just came together on the Chrysler project with the team. Mental Model Do what they would normally do, but at maximum effort took 3-4 months of coaching to get to all those steps at once take everything I knew about software development, and turn it all up Thought this was having the knobs all the way up Since then, have moved to 1 week iterations - fits with the human notion of a unit of time that is imaginable.
- Cancel it
- keep going the way you are going
- Throw away all the code, give everyone a week off, and start over.All successful ventures have a creation mythCompanies and nations have them - projects can use them as well.
Questions from earlier: What about personality issues? Kent - started out shy and introverted. The more people I meet, the more I learn and the better I get at what I do. Having different sorts work together helps. This is why the requirements come from the customer representative.
Question from earlier: How often do clients really get involved? Software as sexual reproduction? Male - business representative Female - Developers Male - leaves 9 months later - the software is born Hurts so much, you aren't even going to try that again soon. (Business rep comes in with a new spec immediately...) Answer - How often are males really there all through pregnancy? What about software as ballroom dancing? Male - business Female - partner work - together If one leaves, it's not dancing Using dancing as a metaphor, software doesn't work unless the client gets involved. You need to get this metaphor embedded, and then it guides the process Metaphors are hard to come up with
Close by talking about another question - What is the value to the customer? Total Effort - No Excuses. Focus and Intensity. Turn the knobs up. Be willing to recognize and try to kill doomed projects
I listened to Scott Ambler's presentation on data(bases) and agile methods this am - there was a lot of good stuff on the issues. Here are my notes:
Scott Ambler - Agile data, Agile databasesMetaphor from this morning - the data (dba) community is packing for Antarctica. Unfortunately, the rest of us are traveling in the desert or the jungle
Data people - want all the info (data model, etc) up front (Antarctica)
- Agile Data Method
- Agile database techniques
Developers - want agility and incremental (Jungle)
Two reactions to the dba
love them - willing to adapt, change
hate them - insists on up front logical data model, paper, validation, slow to change
Same kind of issues between local project teams and the enterprise planners (IT)
The data and developer communities can, in fact, work together
Part of the problem was the early attitude of the OO community towards the data (RDBMS) community
Developers are not working in a vacuum - there is an enterprise architecture that has to be considered
The enterprise staff is theoretically supposed to support, not control, developers
Not them vs. us - only us. have to work together as a team
Need to find the sweet spot - don't fill the backpack to overflowing
Example - Scott's team (Antarctica) died 11 miles from the ship - carrying too much stuff
There is more to modeling than data modeling
Likewise, there's more to software than coding
The Agile DBA Application developers need to understand the basics of Data Models
Likewise, an Agile DBA must understand the basics of programming Otherwise, they cannot communicate effectively. Similar to the translation issue of this presentation - the audience is listening to a Portuguese translation, things might get lost. If we were to work together, we would learn a bit of each other's languages.
There to support the team, not to produce large documents and models. There to help the team implement a vision that fits into the overall scheme. Should roll up their sleeves and get their hands dirty (like a guide on an expedition). One size does not fit all in methodologies and data
Agile Database Techniques for Agile DBA's Database refactoring is, in fact, as necessary as code refactoring but it's much harder What is it?
The act of making a simple change to the database schema The database is highly coupled to your application code, other application code, data import/export routines, reporting tools, persistance frameworks, documentation, etc. Thus, refactoring is hard What do you need?
There actually are testing tools for databases. Use them.
- Strong configuration management system
- Full regression test suite
- Willingness to work together
- Acceptance of your situation
When I'm home, my wife makes sure I get to bed at a decent hour. When I'm on the road, no matter what my original intentions were, I end up staying up late. Off to bed...
There were other good talks today as well - Lowell Lindstrom of OMA was talking about XP in the organization, and Scott Ambler was talking about Agile Modeling at the same time. Cool quote from Scott:
"I keep telling people that there are two languages - Smalltalk, and things that aren't Smalltalk"Alas, as he says, no one listens. I decided to go to Scott's talk, and it was interesting stuff - I didn't take notes, but he had little good to say about UML:
"What does does UML say about Databases?"It was a good talk, and I enjoyed it.
Nothing "What does UML say about the User Interface?"
Nothing "How many of you have ever worked on a system that didn't have either a UI, a database, or both?" Audience laughs
and took notes. He had a good talk, and after the audience opened up, lots of questions. an amusing thing happened (which I only found out about later) - whenever Kent said Smalltalk, the translation came back as personal conversation. That will have to get addressed before I speak, or my talk will be baffling. Anyway, here are the notes I took:
Kent Beck - "Learning to Steer"All in all, it was a good talk, and I enjoyed it a lot. The local audience liked it as well, and asked many questions once they got warmed up.
- introductory caveat - software development varies with culture, ymmv
- Driving metaphor - driving is not about aiming the car, it's about making constant adjustments - speed, direction, etc.
- asks audience for some questions, will put on paper and address them
In the course of the talk, Kent will address the top three
- XP in 5 or size words?
- How was eXtreme programming born (creation myth)
- Is the experience (inexperience) of the team important?
- what is the relationship between XP and RUP
- Conversational dev?
- applying pair programming?
- Is CMM relevant, and can it work with XP?
- Initiation of an XP project?
- XP - relationship with Q/A and testing?
- How much planning is enough?
- Risk management with regards to contracts?
- How does XP scale by project size; is there an ideal size?
- stories and project management
- How much of the dev process does XP cover?
- Partial Adoption of XP?
System Dynamic - reference to physical design and manufacturing
Premise - this is about software, not hardware. The more inventory, the more waste and the less feedback. This is bad One possibility - keep less inventory in order to reduce waste
- break product into discrete steps
- keep machines busy building parts - build up an inventory
- no feedback, so more waste
Question answered - What is the goal of XP?
What is the goal of Software Development - getting a steady flow of quality Kent now admits that he is not talking about machines or manufacturing - but instead about the design/development process, and all the people providing services (analysts, designers, etc). For the last thirty years, we have been pushing for more inventory (documents) Even in manufacturing, little to no inventory is now the goal Refutes commonly held assumption that XP does not involve design - it just attempts to reduce the inventory Work in Process Inventory
-- Unrecoverable investment (Opportunity cost) ---- Types Code Tests Design decisions Specifications Documentation Defects -- Detail not yet in production(Jet lag caught me here - dozed off for about 10 minutes or so)
Very, very difficult to accelerate your development schedules, based on developer expectations alone new style of marketing, sales, customer service, and engineering
what if you have a website, and want to push a release every two weeks?
Standish Group - 85% of features in typical IT systems are never used. The key is to pick what you don't implement, and you go 7X faster Inexperienced teams will have a larger inventory, since they haven't learned what they need to know yet. "Does XP work for inexperienced teams? NOTHING works for inexperienced teams." "How do we use analysts (experts) to help inexperienced developers? XP has many feedback loops, and test-first is the first one. Pair programming is another" This builds experience quickly by constantly improving skills "Do programmers on XP projects need experience to accomplish anything? By definition, half the developers are below average. You will have this issue regardless of the methodology in use" "What good is the coach? Akin to a sports coach - keeps the team moving and motivated. Not having one is no excuse, but it helps "
- Have to move towards a more continuous release process - one without
- formal code freezesC3 - one defect in 9 months of bi-weekly releases LifeWare - What if you want to release DAILY?
- Ultimate in YAGNI - no code in system that hasn't actually been used by a real customer - workflows not requested have not been implemented
- You HAVE to believe that your tests actually cover everything
- Have had one rollback in last two years
Part Two, after a break Questions from the audience
Addressing the questions directly, not going from slides at this point XP elevator speech: - it's a long elevator...
- XP with non-OO?
- XP and Open Source?
- How to estimate cost
- CMM and XP?
- how and when to trust the customer
- documention with XP
- uml and XP?
- client commitment
- stories and requirements management
- overview of XP
- timeframes for XP projects
- what is value to customer
- config management
- cost estimation for XP projects?
- how much planning is enough?
- Gradual implementation of XP?
- XP around the world?
"Imagine if software development were as simple as magic 3x5 cards. When I write something down on the cards, it should take me only a week to implement each card. First thing - given a ship date. I say - we have 12 weeks of work. You say - We have 8 weeks. I say - which 8 things would you like then? Picks the absolute minimum (9) things. I say - sorry, which 8 do you want first?" We call this a satisfied customer. Every monday, team gathers. The coach asks - What do we want to see next? Team says, "these two". Coach says, pick one. Repeat the next week. Discard new ideas that come up, pushing them back to future. XP is your best effort applied to the customer's greatest needs. Continual give and take between parties as to what we can and cannot do in a reasonable time. "My question - how do you deal with big failures, politically disfficult to kill?" Very hard, usually fail. example - 5 years, $100 million Euros in infrastructure, and no software of value yet. Company is in trouble. Future value has
with what you have invested in it thus far. CMM - Copy of the manufacturing maturity model for physical development. But this doesn't correlate well with making money (inventory issue). Increases the volume of documents (inventory) and creates a floor - you cannot go any faster than CMM allows CMM - "How can we write more documents in order to make things run more smoothly?" i.e., increases inventory, while XP attempts to decrease inventory short answer - CMM and XP are incompatible. CMM is about repeatability - but in software, we are always building something different. i.e., repeatability is not that useful "The team owns it's own process" we move people between teams in order to harmonize UML and modeling - Rose (etc) take a long while to start, involves a lot of context switching. UML is also very complex - recommends a simpler method of whiteboard modeling "GML - galactic modeling language ;-)" Line, Box, Label. What more do you need? Semantics - whatever you mean when you draw it Maintenance and UML - NO. Use code as the communications mechanism - and that includes the tests. gradual implementation - ask the team what inventory can be dropped by working backwards through the build/dev process Puzzle - In India (and other low labor cost areas), high tech risk management did not apply, since labor (developers) was so cheap. Wages being low, competing against low wage people doing CMM. Is the higher productivity swamped by the sheer wage differentiator? Can a 10x productivity boost still matter?