Smalltalk Tidbits, Industry Rants

Immo Hüneke 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.

The Pomo Blog reports on the growing importance of the net - relative to TV - for young people:

My youngest daughter (13) was talking about "away messages" and her AOL Instant Messenger last week, so I thought it was time to Google. Apparently, there's a whole cottage industry developing for away messages, and sociologists are studying why. It seems that young people want to live simultaneously in the real and cyber worlds. This is especially true on college campuses. Clever away messages allow a student's "presence" to remain online while they're attending classes. The Web's social network capacity is unlike anything we've experienced before.

Maybe that's why last week's Edison Media Research/Arbitron survey showed 54 percent of people aged 12-24 would rather give up their television than the Internet. This is a significant generation gap, for their parents would rather do the opposite

heh. Maybe I'm not so far gone; I'd rathe lose TV than the net. I see the effect with kids as well. My daughter (13) spends a lot of time on NeoPets (as do most of her friends) and on IM. And she is adamant about leaving away messages and the like. It's a brave new world out there...

I'm with Matt Croyden on this - I'm likely going to buy one of these real soon...

I came in late on this talk - I had to drive to Maindenhead for the afternoon, and just got in after about 20 minutes of the even was done. So here I am - and he's talking about AOP (Aspect Oriented Programming). He sees it as the next step up from OOP - not as big a step - OO from C (etc) was a much bigger step. He sees AOP as a great way to separate concerns, and sees a direct correlation with Use Cases.

Question - While RUP is not the same as Objectory (a side question), what got lost/changed? Objectory 3.8 became the Rational process 4.0 (and then evolved forward from there). Anything lost? A few technology things that he had to accept, never happy with the complexity of architecture in RUP. Analysis was diluted in RUP - partly because it's hard to support via tools (ed - nothing to sell :) ) - so they ended up shortcutting there. Scrapped analysis because it did not fit in Rose (modeling had been supported in Objectory). There are actually still Objectory users (people do like Smalltalk tools :) ).

Objectory looked at the system as a set of models. A lot of things changed in the Rational tools (into view concepts). We identify models, so renaming the concepts was a little overkill. Does not like the term "Executable Architecture". The architecture should remain stable, while models and code will evolve.

Question - What about MDA? Are models (possibly in UML) just high level programs? Even those who are opposed to MDA are actually modeling - it's what we do. MDA means that we create a platform independent model (an architecture). While there are people trying to work on model to code compilers, thus far we only have one way systems, very limited, no real environments. Likes the idea, but thinks we aren't there. Those waiting for MDA are speculating with their company's money.

Side note - modeling survived from Objectory into RUP. Objectory did not handle project management - cared about modeling. In 1989, Objectory sold for $22k per seat. Sold 300 licenses.

Question - Most people associate Ivar with Use Cases. What is he most proud of? Never thought that Use Cases would be so well known and important. Very satisfied with that. Introduced component based development to Ericsson in 1968 - Sequence Diagrams, beginnings of message passing between components - a lot of things that became the foundation of later work.

Question - Which innovation earned the most money? The mistranslation of the original Swedish would have come out "Usage Case" - having it come out as "Use Case" worked.

Question

- Professionalism in Software Engineering - with XP and Agile, more emphasis on craft/art - we don't seem to aspire to engineering. Is that forwards or back? The split view of software as a profession or craft has always been there. Progress is up and down - one of his favorite languages - Smalltalk - is coming back. Has worked to understand how to develop software and identify models and processes to simplify it. Ivar believes that it is an engineering effort whereby we can learn to be better. Refuses to believe that it is a craft at which only a few can be good.

Question - "XP Doesn't help you grow an organization" (quote from Ivar). Lots of good in XP - agility and speed. Has always viewed his work as improving agility and speed. The idea has always been to understand and model the steps involved. XP is substantial in terms of what we can gain from it. XP is something Ivar would use for every new project he would start up. XP has put together a lot of pre-existing good ideas. As soon as something succeeds, we need to grow the organization. The original team will leave - can a lightweight process support the ongoing development and maintenance? His new company, founded with his daughter and developing intelligent agents - uses a lightweight RUP. User Stories (Use Cases). Used Analysis, some model driven design, did most of the work in code. As the project grew, they needed more processes.

Does not disagree with XP - the knowledge is in the heads of people, and if they leave, away it goes. A process like RUP leaves that knowledge behind to be picked up. So XP is a way to begin, but not necessarily how to proceed at all times, especially after growth. RUP does not need to be heavyweight

Question - Any (technical) regrest? Got this question at an OOPSLA conference. Good friend of Dave Thomas. In 1988 he was visiting Ivar in Sweden. Looked at Objectory. He suggested two things:

• Write up how Use Cases work in 125 pages or less
• Let me design a tool for you that supports it, for $100k

Thought that writing such a slim book and such a slim tool was not useful. Thinks now that it would have been fun and useful

Question - What are you doing next? Look at automation (all of software is about automation). Look back 100 years - Ericsson did first switch in 1923 with relays. When he joined, each new feature became much more expensive - software got around that. Now, we are back to the point where adding new features are getting to be more and more expensive. How much of the software we get (in phones,etc) do we really use? 10 percent? 20 percent? We need active software that figures out what you want to do and teach you (instead of passive tech, like what we have now). His company (see above) is in that space. Thinks this will take awhile, and keep us all busy :)

If graphics in Smalltalk are of interest to you, then this talk on CAD at StS 2004 is a must see. Register today!:

3D CAD Framework for Smalltalk
presentation
A-S Koh:
Tuesday 2:45:00 pm to 3:30:00 pm

Abstract: 'StCAD' is a basic 3D CAD framework in Smalltalk (VisualWorks 7.x). It extends the GF/ST 2D drawing framework into 3D. It also include 'StGeo' which is the 3D geometric domain, 'StMath' which provides the mathematical support for 3D CAD and motion simulation computations, and 'StDoc' which is a simple word processor. 'StMath' is also suitable for engineering, scientific and business computing. The parcels are open source using Lesser GNU Public License. Users can use these parcels with other private software to create 3D applications like motion simulation, finite element analysis, CAD, scientific visualization, etc.

'StCAD' allows users to create and manipulate assemblies, which are collections of 3D parts. The parts are 3D solids, which can be connected by joints, constraints, contacts, actuators, springs, dampers or forces. The parts and connections define the structure or mechanism that the assembly is meant to represent. Animation is possible, if the user can provide time series of position and orientation data for the parts.

Users can also obtain output data in the form of plots and tables. XY plots can be zoomed and set to equal scales. Data series available include linear and angular displacements, velocities, accelerations and other user generated data.

'StCAD' has been used to create a freeware called 'freeCAD' which is a 3D CAD with Motion Simulation. The parcel 'StMbD' has been included to provide a functional demonstration, but its source code is hidden. For more information visit: http://www.askoh.com

Bio: http://askoh.com/webcv.html

See you in Seattle!

I've had people telling me for quite some time that I should be looking at Mock Objects - so I've decided to attend a morning session on the subject. I've done ad hoc mocks, of course; most Smalltalkers probably have. This talk is more specific though - there's an example to walk through

The example is a stock trading application. The presenters are using a TDD approach and a Mock framework for Java. One thing that falls out of this is that the Mock framework represents a code specification - an outline of the interfaces and API's that will need to be created. Interesting side point on the mock framework - it's a Java port of a Python port of a Ruby framework - both of which, according to the presenters, are simpler. Always the way...

One interesting fallout - more of TDD than of mocks, but having convenient mocks makes it easier - is that code smell is easier to detect early, when refactoring will be simpler.

Misconceptions about Mocks

• Mocks are just stubs
• Mocks should only be used at system boundaries
• They advise using the real (database, etc) at system bounds instead. Use mocks for internal systems (i.e., those which you have control over). So you would mock your interface to an external system rather than the external system.
• Gather state during the test for asserting at the end
• Testing with mocks duplicates code
• Mocks inhibit refactoring due to many tests failing together (countered by the example)
• Mocks should contain behavior that simulates the runtime environment
• Mocks should be a specification for what happens, not a specification for how it happens

Assertions - Lessons about Design

• Need-Driven, top-down design leads to a leaner system with higher business value
• ed - What?
• Create interfaces for the services an object requires, not to represent all the features an object provides
• Only mock objects you can change
• test how object references are passed around the system
• Getters are evil, setters less evil
• ed What?
• Visit, don't iterate
• ed - A Java issue :)
• Too many mocks?
• object is doing to much - refactor
• Cannot introduce a mock to an object?
• See above :)

Questions from the audience

• Where does architecture fit in?
• What about creation of objects

So on to the "last lap" here. We had kind of a "roundtable" on problems that we've seen, been near, or helped create - that then led to project failure and/or crisis. So:

• Toot your own horn - if you don't, no one else will :) "Heroic" acts (often as a result of the "hero" screwing up) get rewarded - steady, good, quiet work rarely gets recognized
• Social success (golf with the boss, for instance) often leads to more success than does actual work
• Fixing the wrong problem
• Doing a project with new/trendy tech because management read a magazine, or the developers want to refashion their resumes
• Sticking with old tech for too long so as to stay in a "comfort zone"
• Death marches in general
• Announcing a launch date before there's a contract or requirements (Consulting firms!)
• Ill advised mergers - of corporations or internal teams (not that I've seen that :) )
• Focusing efforts on bug fixing to the exclusion of all else, w/o ever really paying attention as to whether the fixes are making customers happy
• Tensions between sales/marketing and engineering - either engineering taking too long for some "perfect" system that never arrives (hurts sales), or sales demanding customer specific fixes that may not be generally applicable - and thus disrupting new development

We drew a picture of that one:

The " " signs indicate pressure from one end exacerbating problems on the other. What you need is less "over the wall" and more face to face (issue for many offshoring projects, in the opinion of the room). We had another diagram that entered into this:

That diagram is trying to show the relationship between work that gets done, work that gets done with issues, and productivity - one can design models to predict where the "best" place to fix things are - but there are always tradeoffs.

That's about it - it was a great session, and I've only captured a pale shadow of it here. I'd welcome expanisons by any of the other attendees!

We had another break, followed by a discussion on capacity. In this sense, capacity means how much can be done in a given stretch of time. This of course gets matched up (not often well) against expectations. We spoke a lot about the tendency of management to exert "work smarter, not harder" pressure (which leads to overtime). I noted that it's not only management that does this - engineers often do this to themselves via a congenital inability to say no to any new, interesting task that floats by them. So this led to another game:

Here's the rule - On each card there's a letter on one side, and a number on the other. How many cards have to be turned over to prove this assertion:

Is there always an even number on the other side of a card with a vowel on it?

This is an exercise that has apparently been done with lots of people, across loads of different domains (software, scientists, etc). It's common to get it wrong; the answer is left as an exercise to the reader :)

This led to a break and a short diversion - we paired off, and one person drew two circles on a page. We then took turns, and then ended with a name when anyone paused. What we got was an emergent diagram - the metaphor being that projects can fail simply through fear of saying I don't know to something. That took us to a discussion of project failures - but I'll get to that in the next post

After a break, we had a new game presented to us - this one was designed to demonstrate the kinds of communication issues that can crop up. Here's what we got:

We had one person on each red space, one person on each blue space. The goal was to get the people switched from side to side, given a set of rules:

• You can move forward one space
• You can "jump over" (like checkers) a person so long as they are facing you (started on other side)
• Each person was given one bit of the rules, and they could only be described verbally (we couldn't throw them on a table and all read them)
• The space we used was all in the hall (i.e., narrow). It was hard for people on one end to hear those on the other)
• When trying to do the move, we could not talk at all

This meant we had to practice. We did that using cards, and came up with hand signals for use during the actual run. We found that doing the practice run face to face with cards was invaluable - we then executed the actual run flawlessly. A few things we saw:

• Not everyone was playing - those observing affected the system - a "Heisenberg effect"
• During our planning, no one got frustrated - one guy immediately figured it out. Thus, no one grabbed a deck and went off by themselves.
• We knew it was possible (some had played before)

This was something of a metaphor for communication problems - the hall was like coordinating by phone instead of having a direct meeting. This led to a discussion on offshoring, and how communication would be an extra problem.

Anyway, more later - the keynote is beginning

I attended an interesting session this afternoon - Seeing the Forest and the Trees by Martine Devos and Diane Gibson. I've never attended a session quite like this; it was interactive, and a half day (1 pm - 6:30 pm) long. It didn't feel long though; the session flowed very well. The women running the event are R&D people, who work mostly on team focus/communication issues. We got an inkling of that in the first ice breaking exercise:

We split into pairs, and we were told to see how high we could score in thumb wrestling. So, we all went at it, competitively. Then Diane and Martine showed us that by cooperating and taking turns, we could score higher - as a team. That set the tone for the rest of the session, and most of us were pretty well hooked.

That led to introductions - everyone selected a picture (from a large set of postcards) or a small stuffed animal as a metaphor - either for themselves, or for what they did at work, or for what they hoped to get out of the session. I picked a picture of the Milky Way, with a "You are Here" pointer to the Sun (as with Smalltalk, "out of the mainstream" :) ). The selections were interesting:

• A bear with a duck swim flotation device - this person was just hired to be a team lead/team builder, and he saw it as unfamiliar territory - like the bear.
• A bat - "Wraps around a problem", has powers that others lack (night flying, etc)
• Mine - out of the mainstream (but highly useful!), just like Smalltalk.
• Next person - a picture of a girl lying on top of a chalk outline of a bike in the bike lane. This guy was going to be a team lead, and he was hoping for some help/direction - from anywhere
• A Zebra lying down - but the animal was actually a bear in a zebra suit. So is it a bear, or a zebra? The idea is that this represented the ability to talk about a subject w/o actually talking directly about it.
• A person working on a project that cuts across operational boundaries, and which may become a product (for sale). Picked a loud, green frog - said it looked troublesome, like his project
• Working on product design - selected a pink elephant. The product is for traders, who need short term answers, but within the context of a long term solution. i.e., the conspicuous "Elephant in the room" needing discussion
• Martine selected a starfish - "Likes to be the star". The Starfish is actually a wrapper ona different character - "fear of failure"
• Picked a Red Fox - need to look "outside the box", beyond the normal context for project solutions
• Diane picked a jester - funny, but also a truth teller
• 2 pictures of an eskimo - this guy had been to Greenland in the winter (something he said we should all do!) - and that reminded him of his project, which is being developed and deployed in multiple countries. He's the project architect - gathers requirements, gets credit/blame - works with people in a foreign (to him) country - thus the picture of a "remote" people
• A Purple bat - Flies in the dark (like her new job - no clear idea of her role yet). Hoping not to crash into anything, company is experiencing rapid growth (120 - 200 in her area the last year) - lots of issues to deal with. Bat can also "completely hide itself"
• Chicken - hiding inside is someone doing a workshop later this week
• Monkey with a red snout - consultant on a large project. Thousands of people, hundred in the IT dept (at this company) - hard to figure out what is going on - many people working "like a group of apes in a forest"
• Picture of a jazz band - individual players who come together for a gig - like a project team
• Lion - "King of the Jungle" - Stalking problems in the system, Focus on them, kill them, sleep in the afternoon. "beast of power"
• a Six String guitar - no expectations for the workshop, decided to come on a coin toss. Strings are for making music - must be played together and "in tune". Have to make a willful effort to get people to work together well

So, after the introductions we were asked to rate (personally, and on a communal board) this activity and all activities of the day on this scale of questions:

• How do you feel?
• What Happened?
• What did you learn?
• How does it relate to your work?
• Any "What ifs" or "What Nexts" ?

That took us to an interesting problem in scaling. We were given two decks of cards, which were mixed on a table. Two people were picked as implementors, one more as a customer. The customer determined how the cards should be sorted, and then the two implementors had to execute that while being timed. Here's what the customer wanted:

• Red deck on top
• Blue deck on bottom
• Cards within a suit sorted, Ace low
• Suits ordered by clubs/diamonds/hearts/spades

The two people each sorted a pile, and then they sorted the suits, one suit per person. That took 5 minutes, with some of the time engaged in planning. Then we got all 14 of us together, with 7 decks of mixed cards. The decks were different sizes as well, so a requirement that they be stacked biggest to smallest was added. We had to determine a process to use, which was simple:

• Each deck was sorted from the mixed pile by one person
• That person dealt out the suits to 4 other people
• Each person receiving a suit sorted numerically
• The individual decks were recombined in the right order
• The decks were peoperly stacked, and ten presented to the customer

We made some mistakes, which needed correction. This all got us into an interesting discussion on the value of Q/A and of up front planning. That got into the differences between manufacturing (which this was like), as opposed to software development. We talked about how we ended up with an emergent plan from emergent, ad-hoc project leaders. That ran through the rest of the day. So we determined that the 2 man job was ad-hoc, with an emergent plan. The larger team developed a pipeline approach, developed by a few emergent team leads. We decided that having someone check the order before turnover (Q/A) would have been useful. A few questions came up:

• Would written requirements have been better? No, but possibly had it gotten more complex
• Would more people have helped? We thought not, even woth more decks (unless we got more than 14, the number in the whole group). That would have bogged down our first step).

So ultimately, we found leaders and ended up with emergent design/planning. Sort of XP like, a few people thought.

That was maybe the first 1 1/2 - 2 hours. I'll post more of my notes on this tomorrow; It's late here (almost 2 AM!), so I'm off to bed.

I attended an interesting interactive event this afternoon - "Seeing the Forest for the Trees". It was a long (1 pm - 6:30 pm) session - very interactive, and very interesting. I have a lot of notes from it, and I'll be putting up a lengthy post on it later. If I feel ambitious, I may use paint to create pictures for it :) For now, off to the reception

Georg Heeg talks about mobile Smalltalk at StS 2004. Georg's people did the port of VW to CE devices (StrongARM and intel based), so this should be a great report - register now to hear it!

Smalltalk Mobilizes
presentation
Georg Heeg: Georg Heeg eK
Tuesday 2:00:00 pm to 2:30:00 pm

Abstract: Smalltalk on Windows CE is the next step toward's Alan Kay's dream of the dynabook of 1973 when Smalltalk got started.

Bio: 50 years old, founder of Georg Heeg eK, Germany oldest Smalltalk enterprise.

See you in Seattle!

Is not quite as simple as Dave Winer implies. To implement it for BottomFeeder, I used the spec here, and tested digest authorization (the hard one!) against a Live Journal feed that Mark gave me temporary access to (thanks Mark!). One thing I learned - those specs are hard to read....

Danny Ayers is working on an RDF API for Smalltalk (Squeak in particular). I expect that'll port to VW pretty easily :)

Slashdot notices Slate, a Smalltalk-like system driven by ideas from Self, Smalltalk, and Scheme. As usual, many of the curly bracer commenters seem unwilling to even think about a system that doesn't use curly braces and semicolons :)

I need an FAQ.... Ryan Lowe confuses strong typing with declarative typing:

Paul Vicks makes a good point when he says that generics make strongly typed languages even stronger, and this seems to go straight against the new wave of weakly typed languages like Python and older ones like Smalltalk.

Sigh. Smalltalk is dynamically, and stongly typed. You cannot get a type error in Smalltalk; if you send a message that is inappropriate, you get a well defined exception (which can be handled). We don't lie to the compiler either (Casting, anyone?). He later asks what the advantages are, pointing to some nice refactoring capabilities of Eclipse. The advantage is that I can define objects in ways that make sense - and have them conform to a specific protocol API. The advantage is that I don't end up with overflow situations because someone decided that 65,535 of something was all I'd ever need. I don't wind up with essentially random types being assigned to objects, just because some type has to be assigned... which makes the whole system more flexible.

Howard Ferch takes on a development management issue at StS - how do you manage multiple version streams of the same project? Register today and find out!:

TAPDance: a system for maintaining multiple versions of software
presentation
Howard Ferch: LynxGL
Tuesday 2:00:00 pm to 2:45:00 pm

Abstract: In order to produce multiple versions of packaged and customized software systems we have developed a system which isolates the user look and feel and database representation from the processing logic. This system stores the definition of all of the user interface in a database, which is read and analysed at runtime. The entire system is written in Smalltalk, and the talk will describe the design goals, how Smalltalk met those goals, and how we use the Smalltalk language itself as a GUI representation language to minimize our efforts in building multiple versions of user interfaces.

We will demonstrate the flexibility of the system by showing how the same executable will provide two different customizations of a Fire/Paramedic dispatching system, as well as a personnel roster system, and a reporting and modelling system.

Bio: Howard J Ferch, PhD, Computer Science, 1978. Currently President of a small software company developing high availability systems for fire and paramedic departments.

See you in Seattle!

Update: Simon Phipps was not only misquoted here, but the journalist who filed the story apparently did not even attend the talk. So it looks like the mud belongs on Julian Bajkowski of ComputerWorld, not Simon Phipps...

Now Here's an interesting story - Sun's Simon Phipp's is ripping Open Source opponents. Maybe he should call Scott McNealy - iirc, McNealy rejected Open Sourcing Java after IBM suggested it...

Only two years after publicly hugging a Microsoft executive live on stage, Sun's chief technology evangelist Simon Phipps has branded opponents of open source "Luddites" and predicted that the current proprietary vendor dominance will crumble through sheer collective will of a new generation of IT managers.

"The Luddites fighting the move to open source are certain to be defeated. Different parts of the software market may move to open source, at different speeds, but the move is an inevitable societal trend," Phipps vowed.

So if we should abandon proprietary software, should Sun open Java, or should developers shun it? Does Phipps pay any attention to what his company does at all?

I haven't posted much in the last few days - I've been visiting customers, going to meetings, and generally been without good connectivity. That should change as I head back to the UK for ot2004, where I'll be speaking about RSS, XML, and Blogs. Assuming decent connectivity, I'll be blogging the talks I attend live - if not, I'll be batch posting.

Sci Fi Wire reports that Buffy (Sarah Michelle Gellar) will not be appearing in the finale of Angel. What will we do with no BuffVerse, and no Firefly?

I had a nice meeting with a customer this morning - they are using Smalltalk (VisualWorks) to schedule the trains for a large part of Germany. That was neat; the system has some very nice graphical pieces with very fast zoom in/zoom out capabilities. That was cool. Then I came back to the corporate (Cincom) office, where I find that the firewall has made life unbearable. All I have is port 80 - no SSH, no IRC, no non-corporate email access... it's like being cut off from the world. Is this what net access is like for most people who work in offices? How do people stand it?

Register now for Smalltalk Solution 2004 so that you can find out what you'll need to do to prepare for Pollock, the upcoming GUI framework for VisualWorks:

Pollock : Into The Breach
presentation
Sames Shuster: Cincom
Tuesday 9:15:00 am to 10:00:00 am

Abstract: Now that Pollock, VisualWorks new GUI framework, is about to come out of Beta and into Production, it's time you learn what it does for you. In this presentation, we will demonstrate the capabilities of the Pollock framework, and how, even in it's first Production release, it surpasses the current framework capabilities. We'll present an overview the future migration and translation tools which will take most of your existing current framework code and move them to Pollock. We will be present the short term and long term roadmaps for the VisualWorks GUI. Finally, time at the end will be devoted to answering questions and addressing any concerns that Pollock somehow represents a disruptive technology change.

Bio: Samuel S. Shuster is the GUI Project Lead in the VisualWorks Engineering Team. After almost four years of thinking about, designing and working on Pollock, he is thrilled that the light at the end of the tunnel is so close at hand. So much so that he actually is making plans to take is first real vacation in almost 10 years... However, he hasn't as yet decided if he'll take his portable with him.

See you in Seattle!

Jeff Eastman, one of the pioneers in distributed computing in Smalltalk, is talking about Open Augment at StS 2004. Register today to see this talk!

OpenAugment: Preserving Engelbart's Augment Legacy
presentation
Jeff Eastman:
Tuesday 9:15:00 am to 10:00:00 am

Abstract: Created in the 1960's by Dr. Douglas Engelbart and his imaginative team at Stanford Research Labs (SRI), Augment is one of the most groundbreaking and important historical artifacts of the software industry. Many of today's desktop and network computing innovations can be traced back to the original Augment system. Today, the OpenAugment Consortium (http://www.openaugment.org/)is taking steps to ensure that future generations will have access to the Augment heritage through its open source initiative. This talk will describe the Augment architecture and the role that Smalltalk has played in its development. It will then trace the discoveries that drove the evolution of the current OpenAugment implementation. Bio: Jeff Eastman is best known in the Smalltalk community for his contributions to Smalltalk Object Request Brokers. A long time HP engineer and now entrepreneur, Jeff was involved in the formative period of the Object Management Group (OMG) and contributed to many of its early works. He later served on the staff of the Object Data Management Group (ODMG) and led their Object Model and Smalltalk groups through three major publications. Recently he has been working with the OpenAugment Consortium to preserve the works of the Augment team on a stable and open computing platform.

See you in Seattle!

Learning Seaside points to a Seaside talk in Bern, Switzerland April 20th. Worth attending if you can!

Here's an announcement from STIC on StS 2004:

In just a few short weeks, from May 3-5, the Crowne Plaza Hotel in beautiful Seattle, Washington will play host to Smalltalk Solutions 2004.

Early Bird Discount!

Remember to sign up before April 3 to receive the early registration discounts. Current STIC members receive a $75 USD discount for the conference. You can easily join STIC or renew your membership while signing up. To register, visit: http://www.smalltalksolutions.com/registration/register.htm

Conference Exhibitors and Keynote Speakers

Some of the top companies in the world of Smalltalk will be exhibiting at this year's conference, including Cincom, Gemstone, Knowledge Systems Corporation, IBM, and many more.

Our three keynote speakers this year are Avi Bryant, Lars Bak, and Microsoft 19s George Bosworth. They will be offering insightful, dynamically charged presentations discussing such fascinating items as Smalltalk in web development to making embedded systems serviceable.

An Educational Experience!

The conference will also offer informative, in-depth, educational tutorials as well as discussions and information on future Smalltalk plans and directions.

Accommodations

When you register for the conference, don't forget to book your hotel. Smalltalk Solutions will take place entirely within the Crowne Plaza Seattle hotel. Make sure to mention you are attending SS 2004 in order to receive a significant hotel discount. Hotel rooms are booked on a first come first served basis, so make sure to make your reservation right away. More information can be found at: http://www.smalltalksolutions.com/hotel/hotel.htm.

26 Add a Little Entertainment and Socializing!

Keep your Tuesday night open while in Seattle because the STIC has planned a fun-filled night for conference attendees at the world-famous Seattle Space Needle. We have reserved a banquet room high above the Seattle skyline for you to enjoy. Hors d'oeuvres and drinks will be served starting at 6:30 p.m. followed by a delicious dinner and entertainment later in the evening.

Register Now!

May is right around the corner and the conference will be here before you know it. Don't forget that registering before April 3, 2004 can result in significant savings to you!
To register, please visit http://www.smalltalksolutions.com/registration/register.htm.

We look forward to seeing you at Smalltalk Solutions 2004!

The Smalltalk Industry Council

See you in Seattle!

StronglyTyped points to a useful RSS utility - generating an RSS feed from Windows Event Logs. Cool

PR Opinions talks about the big screwup Coke made with Dasani in the UK. This brought to mind this post from Ted Neward - a bad customer service story. Here's the kicker - it used to be that bad service, or even a bad marketing campaign, had limited fallout. Now, it's potentially global:

It's also and interesting example of how the geographical barriers for crises are falling, this story has been covered all over the globe: UK Story, US Story, Australian Story, New Zealand story, African Story.

Marketing and PR people have to be very careful now. Heck, everyone does. Just look at how far this John Gray suit threat story has spread. Things can get lost on the web - or they can blown up into super-sized stories. It's a new world out there

Scoble says he wants a feature I don't follow:

Anyway, here's a feature request for the Outlook team: I want a magic folder.
What would this magic folder to? It'd post to my blog everything I drag into it.

What does that mean? It would repost the content? Post a link saying "Look at this?" Typically, when I want to blog something, I want to comment on it...

Chris Double talks about stackless operations, showing a process that migrates back and forth across systems as an example. I've done this in Smalltalk, with a stack, using BOSS to serialize a process, send it across the wire, and have it run. I suppose I could make it come back the same way...

CeBIT is just a massive show - unless you've been here, you literally hav eno idea how big - 22 halls, each as big as the typical trade show venue - software, hardware, consumer goods - it's mind bending. I just spent an hour browsing, and only made it through 5 halls....

It's been a trip so far. Th eflight to London was ok - but here's a tip - don't fly into Heathrow and drive to Gatwick. I'm not familiar enough with the roads to have done that tired :). I finally arrived at my hotel, only to find that I'd been transported back in time - not only was there no internet connectivity, there were no phones in the room! I had to rent an alarm clock...

I had forgotten my itinerary, and making a calling card phone from a public phone boot was an odyssey of begging for operator access. That done, I finally went to bed. Got to Gatwick this morning, hoping to find some WiFi access.... not a chance, not even in Starbucks (there are 2 signals, neither of which gives me net access). So I'm slogging completely off the grid now... who knows when I'll be back on. On to Germany, and hopefully to network access...

Register now for StS 2004 so that you can get all the latest news about Cincom Smalltalk's Opentalk progress - you can meet the protocol team and tell them what you think!

Opentalk, Load Balancing, and Multi-Image SUnits
presentation
Leonard Lutomski: Cincom
Tuesday 8:30:00 am to 9:15:00 am

Abstract: This talk will demonstrate the new Cincom Opentalk Load Balancing Facility and its designed ability to support several different load balancing architectures. The multi-image SUnit framework used to develop and test the load balancing facility will also be addressed.

Bio: Leonard Lutomski has been developing in Smalltalk since 1985 and manages the Cincom VisualWorks Protocol Team.

See you in Seattle!

0xDECAFBAD points to a net based fundraising effort to save Angel (the TV show). This is an attempt to harness the web in the same way that many political campaigns have been doing this year. Will this spread?

BitWorking comments on how hard character encoding is to get right:

Character encoding is hard. Really. If I could point to one thing that causes feeds to be invalid more than anything else, it would be character encoding.

This is the primary reason that BottomFeeder does not reject bad feeds - it just ignores bad characters to the largest extent that it can and moves on. The reality is, feeds move in and out of well-formedness on a regular basis. There are so many people posting so much content from so large a set of tools, that it's simply unrealistic to expect ongoing perfection. I periodically get errors in some of the CST feeds - I'm not entirely certain how, because it's nearly always a comment that came from - somewhere. Easy enough to fix when I notice, but I don't always notice. I'm pretty sure other content producers have the same problem - most of them aren't hosting the server themselves, and most of them have minimal control over whatever it is that the server does. It's not that anyone wants to create malformed content - it just happens. In the meantime, content consumers still want to read the content, even if it has a few bad characters in it for a period of time. Stating that client side applications should just reject that content out of hand is simply anti-social, IMHO. Sure, notify the user that there's a problem with the content, and let them contact the provider if they feel like it. In the meantime, you shouldn't punish grandma because of an error she has no control over...

Patrick Logan reminds me of one of the reasons that Smalltalk is such a pleasure to develop in - the ability to read code. That sounds silly - after all, you can read code in any language. Smalltalk makes things easier in a few ways though

• It's "Open Source" in the access sense - you have access to all code all the time. This is true even when debugging - none of the system classes or libraries are closed off. Need to change/modify/work around something? Go ahead
• Smalltalk is very easy to read. Keyword messages in particular make it much easier to follow the intent of the code

Here's an example of the latter - the following code in BottomFeeder is used to parse an XML document from an http source into a Feed domain object:

Smalltalk code:

Constructor parseAndProcess: anUrl into: aFeed.

C style syntax code:

Constructor.parseAndProcess (url, aFeed);

The Smalltalk code just seems clearer and easier to read - the keyword style of messaging explains each argument, making it more like a textual sentence than like code to be decoded. That just makes it easier to read code and figure it out. A common complaint I hear from manifest typing advocates is that the lack of type information hinders that reading process - to which I respond: How? Seriously - the fact that some object has a given type tells me far, far less than an intention revealing selector does - and keyword style messaging makes it easier to do that. I've been put into the middle of large bodies of C code, and in the middle of large bodies of Smalltalk code. The type information just doesn't help in the understanding process all that much. I find it far, far easier to figure out a large body of unfamiliar Smalltalk code than a similar body of C, C , Java (etc). The fact that there's typically a whole lot less Smalltalk code to look at also helps a lot.

You're going to end up reading a lot more code than you write - the easier it is to do that, the more productive you are likely to be.

We have a preferred conference rate with a reserved block of rooms at the Crowne Plaza, but the block is reserved only until April 2nd, after which time the preferred rate may not be available. Also, if we don't have the block filled by then the conference may have to pay a penalty. So it would probably be good to make room reservations before then if you haven't already done so

See you there!

I just made an update to the category search function. I implemented a cache that sped things up, but there was no proper date sorting. Why was that? Well, this is one of those times when my implementation "leaked". Here's what I did:

• Each posting has a category
• I created a cache dictionary, where the keys are the categories, and the values are a collection of files that have (one or more) postings of that category in them (there's one file per day in this implementation)
• The collection was a Set, to prevent the same file from showing up twice in a particular category list

Using a Set, and then not dealing with that was the problem. When posts are placed on the screen, I just iterate over all the posts asked for and render them. That's fine when they are already in reverse chronological order - but a Set is unordered. I hadn't considered that, which is why - until five minutes ago - category searches were bringing back posts in a random order. It's fixed now :)

I'm off to Europe tomorrow morning - I'll catch the tail end of CeBIT, then meet with a bunch of our customers in Germany. From there, I'll be heading to the UK to speak at Ot2004. I'll be blogging the conference - I'm hoping there will be WiFi access. This is a long trip - 10 days. It's likely that BottomFeeder updates will slow to a trickle while I'm on the road - especially if connectivity is an issue.

Register for StS 2004 so you can hear Avi Bryant discuss Object/Relational mapping:

Making relational data first class
presentation
Avi Bryant: Beta4.com
Tuesday 8:30:00 am to 9:15:00 am

Abstract: ROE, the Relational Object Expression library, models relational queries as first class Smalltalk expressions. This has several advantages over using SQL strings directly:

• queries can be built using familiar Smalltalk syntax and without worrying about binding and escaping data
• queries can be easily composed, so that a complex query can be built up over several methods, none of which know any details about the others
• queries look like ordered collections of tuples, but with most operations other than #do: defined lazily; for example, #copyFrom:to: won't pull in any data, but will simply produce a new query with an extra clause
• queries maintain a rich set of metadata, so that, for example, the columns of any query can be automatically grouped by table and its rows mapped properly into objects.

ROE can either be used directly as a better interface to relational databases, or as a new foundation for object/relational mapping tools. Currently, it has only been tested using PostgreSQL and Squeak Smalltalk, but it could easily be ported to other platforms.

And don't miss Avi's keynote on Seaside!. See you in Seattle!