Ticker names and rational behaviour

From the Java Performance Tuning August 2007 newsletter:

Earlier this year, Sun Microsystems swung back into profit after five consecutive quarterly losses. That didn't help the share price, it went down. They announced innovative new products. That didn't help the share price, it went down. They announced a share buy-back. That didn't help the share price, it went down. This month, they changed the company ticker name (the four character name under which the company is registered in the stock market) from SUNW to JAVA. The share price finally went up.

How I read this... spending time on something as seemingly trivial as renaming a ticker name is rational behaviour because the evidence shows that it will positively affect share price... OR ...the publically traded share market encourages businesses to engage in useless activities instead of focusing on things like profitability and innovation.

BarCamp Sydney 2 reflections

This time around topics ranged from social networking to collaboration tools to entrepreneurialism to Ruby and Rails to Garry's Mod to user experience design. I didn't participate as much directly this time to be available for more organisey type things but here are my random thoughts:

• Almost all problems come from people not talking to each other. Over-specialisation has a tendency to cause people not to talk to each other.
  
• When using the term, User Experience, the examples tend to have less of a task performance, goal-centred feel than when using the term, Interaction Design
• Garry's Mod has gotten very sophisticated
• Effective introduction of change would have been a popular topic

Other interesting observations
Only caught the tail-end of the intro given I was looking up something online and then wondered where everyone went.

We naturally created a single location scheduling area (known in Open Space terms as a Market Place) after having started out with schedules per room.

Room 3, which ended up being the lab again had less activity due to distance from everything else.... though we were able to encourage that as a spill-over room when popular topics expanded outside their expected boundaries. Having the Wii near Room 3 might have helped.

Our T-shirt supplier this time seems to have larger sizes than one would expect versus the significantly smaller sizes than you'd expect.

Getting lunch from Chinatown is better than the UTS cafe.

Barcamp is much more unorganised than CITCON which creates a different vibe. I do think we need more structure for recording and communicating what happens in each session. Too easy for it to disappear into the ether.

Things that didn't quite work
The rooms need better air ventilation. The window hinges have cobwebs on them which suggests that they haven't been opened for a while. The auto-locking doors didn't help either. And why is there a video camera pointed inwards in all the rooms?

Most likely look for a new location the next time around.

User testing: Halo 3 style

Via Penny Arcade,

Wired has an article of the user testing that is being done on Halo 3. No matter what they tweak though, I wonder though whether the Wii has already demonstrated that these types of games are competing for scraps.

Keep application logic and roles out of centralised security services

Do not couple the security system (and the associated security team) to application decisions.

Just because a role looks similar between applications, don't assume that each application will evolve their role needs in the same fashion.

They won't.

That's why they're separate applications.

Sunk cost fallacy for architects

Let's say you've bought a movie ticket but then realise from Rotten Tomatoes that the movie stinks. Assuming you can't sucker one of your friends to buy the ticket, you have a couple choices:

1. Since you've paid for the ticket, you might as well suffer through the movie anyway.
2. Throw away the ticket and do something else.

The sunk cost fallacy is not realising that in either case, you've already paid for the ticket and therefore the sunk cost is not relevant for rational decision making.

Case 1: You suffer the cost of the ticket + You suffer through the movie
Case 2: You only suffer the cost of the ticket

Therefore, rationally 2 is the better option.

So instead of a movie ticket, let's say it's an enterprise software license... or perhaps some custom hardware.

Should how much was paid for the license or hardware have any bearing whatsoever on what is decided to be the best future architectural approach?

Well, only if the management system you're operating in punishes rational behaviour and rewards irrational behaviour.

Always explain why

When you're doing a presentation or otherwise introducing a concept, always explain why.

It shows respect for people. It encourages involvement, and therefore commitment. It emphasises that understanding why is just as important as, if not more important than, understanding what or how. It emphasises that if why changes, so should what and how.

...

Someone I know was telling me a story about her husband. When their son expressed confusion about why his toy car flys off when he spins in a circle, he's the kind of father that goes into an explanation of centripetal force, inertia, etc.

Another story.

At the mall, a boy accidentally triggers the store alarm when the clothing gets too close to a store security sensor. The boy doesn't understand how that works and asks his father what's going on. The father responds: "It's magic."

Arghh!

So our protaganist walks over there and tells the boy how it actually works.

...

Respect all people, including and perhaps especially children. Respect anyone who asks a question about why. As an instructor, a teacher, respect your students by learning why and if you don't actually know, say so and then find out.

"It's magic", "Just trust me", "That's just the way it is"... those phrases are simply disrespectful.

Deming said: "There's no substitute for knowledge"

I say: "There's no substitute for sharing knowledge"

Effective enterprise architecture comes from a culture of simplicity

Back in the day, we had these Rules of Simplicity in Extreme Programming:

In order of importance...

1. Passes all the tests
2. Contains no duplication
3. Expresses all the ideas that need to be expressed
4. Minimises classes and methods
   

To put that in another way...

1. It has to work. It has to be easy to verify that it works and keeps working.
   
2. It has to be maintainable. A single change should be a single change.
3. It has to be understandable otherwise it won't be maintainable.
4. Less things built means easier to maintain.
   

We also had this slogan, You Ain't Gonna Need It (YAGNI), which meant that you weren't supposed to build features until you needed to build them.

So what's different when you look at enterprise architecture? I'm encountering a distressing lack of awareness of the importance of testability and maintenance in the inhabitants of this culture. It's all about scaling and partnership relationships instead.

Instead of a culture of simplicity (i.e., you must justify why you're building more than you need to, you must justify why you're building something that is expensive to test, etc.), there is a culture of anticipation (i.e., you must justify why you're not building something that handles every imaginable change).

Well so far, I have not encountered a single organisation where that culture of anticipation has shown observable evidence of effectiveness. I do see a lot of examples of anticipated generalisation that didn't pan out and added significant maintenance overhead that lasts decades.

It's not that all anticipation is unjustified. For example, I would be watching out for decisions that eliminate options. However, YAGNI and simplicity should be the default with exceptions to be justified, not vice versa.

Why standing up is still important

Steven M Smith has been rethinking stand-up meetings, especially questioning the standing up aspect.

I know people from an earlier era who believe wearing a tie makes developers more alike and more disciplined. I don't buy it. And I don't buy the idea that participants should keep standing up once they understand the rules for participation. Forcing a developer to continue standing up is like forcing them to wear a tie. Both actions will make them uncomfortable and neither will improve their productivity.

These seems pretty reasonable and I would tend to agree that standing up is not a goal so much as a tactic to achieve a goal. However, I'm wary also of ignoring evidence.

Hard Facts describes a University of Missouri experiment comparing 56 stand-up meeting groups vs 55 sit-down meeting groups.

Groups where members stood took 34 percent less time to make the assigned decision, and there were no significant differences in decision quality.

This doesn't mean that other factors were not in play but even if it's not just about standing up, standing up might still be rather important.

Prioritise to maintain options

Every feature implemented before its time removes an option to defer that feature to protect schedule.

Are your compile times long enough to have a sword duel?

This comic from xkcd is so old school to me that I did a bit of a double take.

If you replace, "My code's compiling" with "I'm waiting for the build to pass" where "build" includes tests... but even then... I'd be looking at optimising builds rather than fighting with swords.

BarCamp Sydney 2, Saturday 25 August 2007

BarCampSydney 2 is just around the corner.

What: BarCampSydney 2
When: Saturday 25th August - one day only
Where: University of Technology, Sydney
Time: 9am
Cost: Free

Register: http://barcamp.org/BarCampSydney2
Blog: http://barcampsydney.org/
Facebook: http://tinyurl.com/29enmw
Upcoming: http://upcoming.yahoo.com/event/236162/

How dies it work?

Register on the wiki. Suggest a topic you may like to cover. Come along on
the day and help develop the schedule.

Take part in free form presentations, discussions, debates, panels -
whatever takes shape on the day.

Get involved. Take part. Have fun!

We all look forward to seeing you all again on the 25th!

Weinberg's 7 criteria for taking on a new consulting assignment

Gerry Weinberg offers a set of principles that he has always used when taking on a new consulting assignment:

1. I will not work for an organization whose goals are not consonant with my own beliefs.
2. I will not work on projects whose goals I do not understand, or cannot agree with.
3. Before becoming part of a project, I will first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.
4. I will not work under measurement schemes that pit one person’s performance against another’s. Rather, I will cooperate totally to help others in the project achieve their full potential, as I expect them to help me do.
5. I will not accept work without understanding what is to be done, and why, nor will I pass work to others without their similar understanding.
6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by real security considerations); and I will always stand ready to review the work of others in exchange for them returning the reviewing service to me on my work.
7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my project and the organization that has retained my services.

PLoP 2007 final Call for Participation

CALL FOR PARTICIPATION (final)

14th Conference on Pattern Languages of Programs (PLoP 2007)

September 5-8, 2007 - Monticello, Illinois, USA
http://hillside.net/plop/2007/


*Early Registration till 19th August*
http://hillside.net/plop/2007/index.php?nav=registration
******************************

***************************************

*About PLoP*

Pattern Languages of Programs (PLoP™) conference is a premier event for
pattern authors and pattern enthusiasts to gather, discuss and learn
more about patterns and software development.

Patterns authors and non-authors will find in the different PLoP
activities (Writers' Workshops, Writing Groups, Focus Groups, BoF
sessions, BootCamp, Games) many opportunities to meet and learn more
about patterns and pattern writing.

As a whole, the conference provides a friendly and effective environment
to give and get feedback, to share expertise, and to allow the
participants to improve their knowledge about patterns.

*How To Participate*

If you are not an author of a paper accepted for PLoP'07, you can still
participate actively by enrolling a *Writing Group*, or proposing a
*Focus Group* or *BoF*.

*Writing Groups* are primarily for participants willing to start writing
their first pattern, or to continue evolving their work-in-progress.
Writing groups aim at providing authors the opportunity to work on the
their patterns in an interactive session mentored by an experienced
author specifically assigned to each group.

Papers on the writing groups are typically papers that, at the end of
the shepherding process, were considered that would profit more from an
interactive session to work on the paper than from a writers workshop.

After the work done in the writing group, some papers will be selected
to be discussed in the final session of a Writer's Workshop at PLoP'07.
Another possibility is to further evolve them after PLoP'07 and submit
to the Mini-PLoP at OOPSLA'07, a full-day Writers Workshop.

*Focus groups* are free-format discussion groups or workshops aimed at
bringing together people interested in a hot topic related to patterns
or proven practices, for a period of about two hours.

These sessions might focus on very different topics and issues related
to patterns, ranging from writing to using, organising, or adopting
patterns. Focus group proposals should include a brief description of
the topic to be addressed, objectives, format, conditions for
participation (e.g. invitation, submission, free, etc), and a schedule
outline. Proposals addressing interdisciplinary topics and topics from
other domains than software development are especially encouraged.
Non-conventional formats are welcome.

Focus group proposals are reviewed by the program committee. Focus group
leaders are expected to write a report to be part of the final
conference proceedings.

*BoF ('Birds of a Feather')* is a shortening of the proverb "Birds of a
feather flock together.", meaning that people (birds) of the same kind
or interest (of a common feather) enjoy spending time (flocking) together.

BoF sessions are informal meetings, usually scheduled and organized
lately or even on site, where people group together based on a shared
interest and carry out discussions without any pre-planned agenda.
Everyone may propose a BOF session to the conference chairs, on or
before the conference.

*How to submit*
To participate please submit your idea or work-in-progress till *17th
August*, by email to plopsubmissions@hillside.net. The submission can be
as minimal as a 200-word abstract or a full paper under development.

*How to register*
PLoP online registration has opened on May 15 and will be possible till
August 19, 2007. We strongly encourage early registration for better
room arrangements and conference service.
URL: http://hillside.net/plop/2007/index.php?nav=registration

*Important dates*
Aug 12: Conference Drafts due
Aug 17: Writing Workshops submissions due
Aug 19: Early registration ends
Sep 5: First Day of PLoP

*Chairs*
Program Chair: Joseph Yoder (The Refactory Inc., USA)
Conference Chair: Ademar Aguiar (FEUP, Universidade do Porto, Portugal)

*More information*
For more detailed information, please visit the PLoP'07 website.
http://hillside.net/plop/2007/


We will look forward for your participation.

Best regards,
Joseph Yoder and Ademar Aguiar
PLoP 2007 Chairs

P.S. If you think that this conference may be of interest to
colleagues, friends or communities to which you belong, please
forward on this email. Thank you.

--
PLoP is a trademark of The Hillside Group, Inc.
--




========
Joseph W. Yoder joe@joeyoder.com http://www.joeyoder.com
The Refactory Inc & Joe Yoder Enterprises Phone: (217) 344-4847
7 Florida Drive, Urbana, IL 61801 USA Fax: (217) 384-4458