1. Go to Presentation > Widgets.
2. Drag the Flickr widget onto the sidebar.
3. Open the configuration dialog. Give it a title and a RSS feed URL you copied from the Flickr your album’s page or a specific set’s page.
4. Save changes. Sit back and enjoy.

But I can only see titles of photos displayed in the widget but not photos. It happens that the Flickr widget WordPress.com installed only works with RSS 2.0 and Flickr has changed its default RSS feed format to Atom RSS. So to make the widget work you have to make Flickr gives you RSS 2.0 feed.

It took me a while to figure out how to do it. Simple append &format=rss2 to the end of RSS feed URL you copy from the Flickr page.

Example
URL copied from Flickr:

http://api.flickr.com/services/feeds/photoset.gne?

set=XXXXX&nsid=XXXX@N06〈=en-us
Modify it as
>> http://api.flickr.com/services/feeds/photoset.gne?
set=XXXXX&nsid=XXXX@N06〈=en-us&format=rss2

There is WordPress forum post talking about the issue. It first suggested that you can find the URL for RSS 2.0 feed by looking at the source of Flickr page. I am not sure if you can found it early this year when things are in the middle of transition. But today I look into it I only found 1 URL for Atom RSS feed. The last post said Flickr has restored to give RSS 2.0 feed that the widget should works again. Well, it doesn’t work for me so may be Flickr has changed their mind again.

If you are interested in how I am inspired to find the solution, go visit Flickr Services > Feeds.

Anyway. Enjoy~

Is a dedicated room for developers matters?
Or the way we let developers doing their job matters?

I say the latter. We want to be in a room because we are getting most of our job done happily and productively when we work alone.

WE ARE BEST AT WORK WHEN BEING ALONE.

A room is only one of the factors that makes this happen.

This might sounds like a statement in the favor of people who have the excellent capability and interest sitting in front of a computer all day long without speaking a word. But one one is an exception. All right, you are not a lonely guy. You might be socially active. You may be welcome by everyone. You love making new friends. You love talking to the others . You love helping the others out. You just love everybody (/hug). But the work-alone-is-the-best principle would still applies to you. Why?

Multi-tasking makes people slow and stupid, as suggested by Walter Kirn in his article “The Autumn of Multi-tasker“. It is not necessary any physical tasks to be assigned to one to cause the problem. Just anything such as chatter, phone calls, emails and instant messages that derails people’s mind can do the harm. They blow away your new ideas and short term memories, keeping you start over and over again the thinking process in order to finish the works at hand.

Experiments executed by authors of the famous book Peopleware have proven the negative relationship between productivity and office noise level. Guys at 37Signals have even suggested that you should setup a rule requiring every one in your team to work alone for a certain period of time everyday. So that every one can get his work done happily and effectively while still keeping the communication between team members.

So locking up your developers in a room will probably do good to your company. You keep these mind workers concentrated on their creation works at least with a physical mean. The bottom line is, however, you have to honor the rule of silence. If the room is nothing more than a room and developers are still getting interrupted in numerous different ways other than nearby chatter and calls, you might have been send the developers into prisons.

Believe it or not, if you lock a team of developers up in a room with computers and leave them for a sufficient long time, they will either give you a master piece of software, or a completed work of Shakespeare

Days ago my colleague forwarded me a post from Jason Fried at 37 signals, the company who created Ruby on Rail, talking about the story of how they designed and implemented a new product feature. It’s inspiring. To me, it recalls of two lessons I’ve been taking for long during my development career: small problems over big problem, small solutions over big solution.

People love GENERIC stuffs

It is always a habit of people, essentially developers, to think big ahead. But why? Cos it is commonly believed that every body can do small solutions but only the smarts can think big stuffs – designs crafted to “potentially”do many things ahead with minimal amount of effort. So physicists have been working for hundreds of years on a unified theory to describe the world. So process designers and theorists have been dumping standards of business process flows that claimed to fits organizations from small local firms to international enterprises. So we developers work to death for generic classes, abstract implementations, standards, frameworks.

It’s just a shame to let your fellows found that you have duplicated logics or codes in your development work. Even sometimes the things in common are only bean properties of identical names. It’s just not a pretty if you don’t implements as many functions as you can with minimal number of lines of codes. The name “generic” just rocks. People creating generic things are stars.

Last but not least, money matters. The more generic a design is, the more likely it is offering functions people need. More need more money. So you boss love it. And you should love creating it.

It’s all basic instinct to love big and generic things. But should you?

Suppose you are going to design and implement a little library systems that let the staffs borrow and return books in a self help manner with a browser. Okay, let’s write the story down first…

“User can borrow and return books”.

What do you need to implement it?

• Book - The model representing a book.
• BookManager - Service class providing borrow and return operations.
• BookDAO - Data access component for saving the data to a database.

Simple enough, right? “It must be too simple. I must have missed something.” You said to yourself.

Oh… oh…. but wait. People borrow “things”. There are many assets in your company are borrowed and returned frequently and yet your company still don’t have a system to manage it. Notebooks, VCR, projectors, salary (Yes, you can borrow your next month’s salary ><b). Genius, perhaps you can expand it a little bit to make the design capable of handling these things as well, potentially. Let’s do it.

• Resource - Interface decorating any “things” that are allowed to be borrowed and returned.
• AbstractResource implements AbstractBorrowableResource - A default yet abstract implementation.
• Book extends AbstractResource - Implementation for book.
• ResourceManager - Interface defining a service that handles operations related to borrows and returns.
• AbstractResourceManager implements AbstractResource - Implementation of service for others to extend and implement the real stuff.
• BookManager extends AbstractResourceManager - Implementation for book service.
• ResourceDAO - Interface. You know what it is. I am lazy.
• AbstractResourceDAO implements ResourceDAO - I guess you know.
• BookDAO extends AbstractResourceDAO – Cough~ Cough.

Looks great now. You now got an extensible hierarchy, interface driven. What else do you need? Yay~ Yay. Modules.

It is generally good to separate the API and actual implementations so that when people code in parallel without caring if you are in a fighting hard to get your implementations compiled. With API extracted the API itself might be reused in other projects as well, though you can’t think of what sort of projects would like to include it at the moment. Yes, it is generally good. So you do it in 2 modules: resource-api, resource-code. Out of luck your favorite IDE you-know-which does not support well multi modules development so you spend quite a time figuring out the right way to do it. To meet the deadline you work sleeplessly for days. Finally God blessed you this brave code monkey you got all the things sticked together.

Your manager shows up as you get out of Alice’s rabbit hole, a week behind schedule. He is so highly educated he decided to not to comment on your smelling body. You showed him your work. Nothing happens… Oh I mean bugs. A week later the system is put into production. Staff can now borrow and return books on their own. Managers no longer need to worry about where do their most valuable books go. A year after, people are still borrowing and returning books. You, on the other side, still live as a sleepless code monkey. No other project cares about the API library except the system itself.

It won’t be fun at all if I tell you what’s behind the story. I might have amplified part of it a bit. But most of it are borrowed from real stories. Oh, borrow.

You should love them. But be pragmatic…

You should love big and generic things & ideas. It’s basic instinct. You can’t control yourself not to love them. There are, however, reasons why you should do more small solutions rather than a few big solutions when you layout your development.

1. Real value comes from real things
   Real values of thing only show when the thing becomes real. This is specially true when it comes to user usability. Unless you know well now to generalize an implementation as you might have do it before, it is likely to be a waste of effort to make things generalized before users told the value. You better save your effort on other more practical and valuable targets, or to take a rest.
2. User don’t care!
   User don’t care if you are providing generic features or implementations. They just want their job done. They borrow books. They borrow equipments. They won’t care if the things they borrow are under the name of “resource”. I’ve seen many times applications implemented a so generic way that attempt to do almost everything related to its target scope end up getting users lost in configuration hell and navigation maze. It’s often no single user knows the whole application. If user have need to do common things in a more effective way, they will let you know when they use it. Make it work first, then the real patterns show up when your users get their hands on it.
3. More rolls more wins
   This is what one of my favorite book The Max Strategy: How A Buisnessman Got Stuck At An Airport suggests. Do more small solutions. Join and refactor only when need. By giving more chances the market and users accesses your new ideas, you make more chances of getting success.
4. Diversify risk
   Unless God hates you, or Murphy blesses you, you are less likely to get all the small solutions go wrong. One big solution, go wrong often. Even it has the same chance of going wrong as that of small solutions on average, big solutions still bears bigger risk. As big solution takes more time to develop, you know the result late. That said, as the deadline is close, you got little room to fix it or place an alternative in time.
5. Duplicates != Evils
   Duplicated codes or logics are not evils. They are when first, you never have the idea in mind to refactor it whenever you can spare time or need to do it. Second, they are removed through generalization in an unusable way. That said, they are generalized only because you want to generalize them. Not for value or need. Things look common are not necessary duplicates of each other. Take a real close look. They might just looks similar to each other.
6. Geek you can always refactor
   As long as you follows common good programming practices, say properly organize your packages and encapsulate logics, test driven, you can always refactor to capture the commons.
7. Lesson from the mother nature
   Look at your body. If you ever considered it as one of the finest creation from God, then learn from it. It evolves over time from very simple and small structures to an integrated and multi-function structure today.

Genius-free development

I admit that there are genius in this world who can create master pieces with few iterations. When I was in college taking an A.I course, I worked with a guy to build an expert system for identifying whales as an assignment. He took the job of engine development while I took the front-end part. For days this guy sit in front of the computer, rarely types but spent most of the time meditating while I kept muddling through tons of compilation errors and bugs by his side. Finally he compiled his codes and run the engine. Almost no error pop during the process except a few minor typo. It just runs, smooth and quick. The guy is a real genius.

I am not genius. I believe 99.99% of us are not either. But we can still build big successful solutions. Starts small. Move frequent. Be iterative. It might take more steps then genius do. But for the rest of us, it could be perhaps the shortest path we could take towards success.

You can of course build a site simply by putting a bunch of JSPs together into a Tomcat. But the result is nothing more than a collection of interlinked dynamic pages, not an application. A structured application should be with easy to read, easy to maintain, extend and refactor in a logical manner.

I didn’t quite realize this question until recently I am assigned a few new developers and decided to layout a web application skeleton by picking some bullet-proven frameworks and technologies on the market, in Java camp of course, to let our developers to work productively without getting stuck with traps our development team have muddled through in the past. This is my finalized shopping list.

The stack is huge. Scary enough to hold people back from writing their first web application in Java, after completing their hello-world course. Not to mention the initial lengthy and error-prone setup procedure one need to go through to get all stuff running together … Eclipse WTP, Maven, Spring, Acegi, Hibernate, Tomcat, Blahlala….

15 items on my menu. Holy.

I love Java. It is still my favorite programming language today. It let me build fantastic application to serve people around the world without caring much about the m$ stuffs & hacks. But when it comes to the web, the slope one need to climb so huge that if you are new to these you will be exhausted before making any fun from building your first application. I could be proud of the number of skills I mastered. Yet I would enjoy more if my application can do more for the users, improves in a rapid rate to catch up user’s need and make them happier. Flying is fun. Crafting the aircraft to fly is definitely another issue.

If today some one turn to me and ask “I want to write a web application. Where should I start?”. Try to Ruby on Rails my friend. Get a text editor and Instant Rails, you are off to go.

Missing dependency tools.jar

8/13/07 5:58:51 PM CST: Missing:
1) com.sun:tools:jar:1.5.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.sun -DartifactId=tools \
-Dversion=1.5.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) tutorial:tutorial4:war:1.0-SNAPSHOT
2) org.apache.struts:struts2-core:jar:2.0.5
3) com.sun:tools:jar:1.5.0
1 required artifact is missing.
for artifact:
tutorial:tutorial4:war:1.0-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)


Huh? It misses the tools.jar from Sun’s JDK.

Murders – Mr. profile “default-tools” & Mr. Sun Micro the JDK

I soon dig out that it is the struts2-core artifact has a dependency on Sun’s tools.jar. A profile named “default-tools.jar” declared the dependency on the tools.jar, which is activated when you are running the maven operation with Sun’s JDK. This is what you can see from struts2-core’s pom.

<profile>
<id>default-tools.jar</id>
<activation>
<property>
<name>java.vendor</name>
<value>Sun Microsystems Inc.</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
</profile>


Yet strange enough, I had no problem running the build with my command prompt. It only matters when running in Eclipse. To be exact, there was no problem when I manually triggered the building process by “Run as Maven2 Build” with the pom. But when Eclipse builds the project automatically, say after a clean, the error pops.

Adding the tools.jar to Eclipse’s JDK runtime does not help. Nonetheless this does look like a good practice so I give it up.

So what have went wrong? The profile try to look up the tools.jar by back stepping from the directory java.home, where it is the home directory of running Java process automatically deduced and set by Maven. If java.home points to a JDK, the path works as JDK comes with a tools.jar in the lib/ folder. But if java.home points to a JRE instead, the path should fail as JRE doesn’t bring along the tools.jar. When I start Eclipse, I could have started it by either a JRE or a JDK as I simply doubled clicked the shortcut to it on my desktop. The remaining problem is, isn’t it Eclipse is running the Maven 2 Builder with my configured JDK in the project? So I make the shots.

Starting Eclipse with -vm Option

The configuration free classic way to start Eclipse with desired VM.

$>eclipse -vm "C:\Program Files\Java\jdk1.6.0_01\bin"

Wow! It works. Okay, give it another shot.

Making JDK/bin the First Element in %PATH%

$>set PATH=C:\Program Files\Java\jdk1.6.0_01\bin;%PATH%
$>eclipse


Jesus! it works again.

Conclusion?

It looks like the when Eclipse is told to call the maven build manually with a pom.xml it, it executes with the configured JDK’s path. But when it comes to execute the Maven 2 Builder, it uses the Java process which starts the Eclipse instead. So if the Eclipse’s started with a Sun Micro JRE, it misses the tools.jar for struts2-core. Other JDK/JRE doesn’t matter, however, as the tools.jar or equivalent are usually on the classpath already.

Is it a behavior of Eclipse or just that of the M2Eclipse plug-in? I haven’t figured out yet. May be I just messed all the things up by accident (or luck). If anyone know what’s really inside, let me know

Maven project first? Or Eclipse project first?

Recalls me the old humor “Which came 1st chicken or egg?”. Someone have even setup a whole site for it (http://www.whichcame1st.com/). Um? Cough! Cough … let’s back to our topic. The first decision to make on setting up the maven enabled project, is to decide where to start first.

Maven first – the official way … boom!

Maven comes with a plug-in that helps generate a eclipse WTP project that fits the standard maven project structure and dependency management practices. In theory all you need to do is executing a mvn command with desired WTP version specified. In practices it never works for me, from WTP 0.7 to 1.5. The Eclipse will either told you that there something wrong with the project’s WTP meta or the classpath. Okay, sorry guys I know I am sort of moron don’t know how to fix a cook. But even if you managed to get it loaded into Eclipse without any error, you might not like the way maven is brought into your eclipse either. It brings the necessary dependencies into your project by listing all into the classpath statistically. Here’s a grep:

<classpathentry kind="var" path="M2_REPO/ognl/ognl/2.6.9/ognl-2.6.9.jar"/>
<classpathentry kind="var" path="M2_REPO/org/springframework/spring-core/2.0.1/spring-core-2.0.1.jar"/>
<classpathentry kind="var" path="M2_REPO/commons-fileupload/commons-fileupload/1.1.1/commons-fileupload-1.1.1.jar"/>


Not to mention the variable M2_REPO. This approach probably means you have to re-generate the classpath again every time you updates the dependencies of the project. I haven’t figured out if the plug-in is smart enough to merge changes if it founds a .classpath file on its way. But if it didn’t, god bless you my friend.

Most important of all, the plug-in does not support 2.0 by the day of writing. So boom!

How about if I generate the maven project first, not with the wtp plugin of course, then import into Eclipse and make it a WTP project? Looks feasible. As with Eclipse 3.3 you can add facets to the project through the user interface. If a project is not initially a WTP project, you can turn it into by adding the WTP facet. Our team has once used this technique to save a WTP project which loses its WTP nature after passing through the CVS as the component settings are by default not carried along.

So I do it. For unknown reason my Eclipse don’t like it, there’s no facet configuration option show up in the project properties dialog at all that I found no way of adding the facet. Again, boom! Time to go the other way.

Eclipse first – the alternative official way? … boom! boom!

This is my thought: create a WTP project with structure conform to maven project structure then make it maven enabled with the M2Eclipse plug-in. It should work. At least this is the way I do the setup previously with Eclipse WTP 1.5, which runs on a 3.2 core.

Improvements on products, you know, often comes with more validations to prevent users from making serious mistakes that could turn the product into error reporting service. This is obviously true with the new 3.3, it no longer accepts “/” or “\” in resource name. That means you can specify the web content directory as src/main/webapp and Java source directory as src/main/java according to maven conventions.

I don’t know why they do so. Perhaps the folks at Eclipse don’t like things not placed on the first level. I give up this approach anyway.

Craft by Hand. Dirty. But it works!

Yes it is a hack. It’s not smart at all. I did it with WTP 0.7. Now I do it again with WTP 2.0. Well well, it works. Here’s the approach I take:

1. Open a eclipse, create a reference “Dynamic Web Application” project.
2. Generate a standard maven project with default archetype
3. Copy all necessary Eclipse settings files to the maven project and modify these files to make them fits the project.

If you plan to follow the instructions in below to setup a Maven 2 WTP project, make sure the following are done to save your effort later on:

1. Eclipse 3.3 with WTP 2.0 installed.
2. M2Eclipse plug-in installed (http://m2eclipse.codehaus.org/)
3. A servlet container runtime, could be Tomcat or anything supported, is configured.

Ready? Let’s do it.

Step 1: Create a reference WTP Project

Simple huh?

1. Open eclipse.
2. New project > Project … > Web > Dynamic Web Project.
3. Name project. Select target runtime. Click Finish.
4. Close eclipse.

Step 2: Create a maven project

1. Do it with maven archetype.
   mvn archetype:create -DgroupId=com.mycompany -DartifactId=my-war
2. Add the following folders:
   1. src/main/webapp
3. You might want to add the following folders as well:
   1. src/main/resources
   2. src/test/resources

Step 3: Copy Eclipse files

Copy the following files from the reference eclipse project to maven project.

1. .project (file)
2. .classpath (file)
3. .settings (folder)

Step 4: Edit project setting

1. Edit .project.
2. Find <name>${project-name}</name> under <projectDescription>
3. Change ${project-name} you would like to have with your project. It is recommended that you name your project in only characters, digits, hyper and underscore only, although not strictly required.

Step 5: Edit classpath

1. Edit file .classpath.
2. Find <classpathentry kind="src" path="src"/>
3. Change to <classpathentry kind="src" path="src/main/java"/>

Step 6: Edit WTP component setting

1. Edit file .settings/org.eclipse.wst.common.component. It should looks like:
   <?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
<wb-module deploy-name="${deploy-name}">
<wb-resource deploy-path="/" source-path="${webcontent-path}"/>
<wb-resource deploy-path="/WEB-INF/classes" source-path="${source-path}"/>
<property name="context-root" value="${context-root}"/>
<property name="java-output-path" value="build/classes"/>
</wb-module>
</project-modules>
2. Set ${deploy-name} to your desired deploy-name. This name have no effect on the app’s accessing URL It usually only serves as a meaningful label in servlet container’s administration console.
3. Set ${webcontent-path} to /src/main/webapp
4. Set ${source-path} to /src/main/java
5. Set ${context-root} to the path you want the application to be accessed. Say, “my-app”. Then you app will be accessed through http://localhost:8080/my-app. It is usually good to follow the convention that you can name it with the project name, as long as your project name fits URL naming limitations.

Step 7: Import project into Eclipse

1. Open eclipse.
2. File > Import > General > Existing projects into eclipse.
3. Browse the directory where your maven project is located. Click Finish.

Step 8: Post configuration

Nearly done. Just a few more steps to make maven works smoothly with WTP. Make sure that you have M2Eclipse installed before you go.

1. Enable Maven support
   On the project context menu, select Maven 2 > Enable.
2. Include Maven Dependency to Web Library
   Project properties > J2EE Module Dependencies> Tick “Maven2 Dependencies”.
3. Add additional maven source paths.
   By default the project only have src/main/java in the source folder list. Maven directory structure, however, comes with multiple useful source folders. Add them to the list as well:
   1. src/main/resources
   2. src/test/java
   3. src/test/resources
4. Set order for libraries
   Project properties > Java Build Path > Order and Export, set order as: src/main/java, Maven 2 Dependencies, Web App Libraries, blahalala…
5. Set order for builders
   Project properties > Java Build Path > Builders, set order as: Maven 2 Project Builder, blahalala…

Step 9: Ready! Set! Go!

Clean your project. Let it build automatically. You might need a eclipse restart or a few more rounds of clean if not all the things work out immediately.

This is how I get my first Struts 2 tutorial running with Eclipse WTP 2.0.

The Rebel

It is heard that Intellj IDEA 7 comes with out-of-the-box support to Maven. I will try it out soon to see if it really works as advertised. Before that, if you are interested you might take a look at Stefan Reuter’s post Using Maven with IntelliJ Idea 7.0.

If you know better anyway to do the integration, please let me know. I seriously looking for better methods

Our China office was located at a science park quite a distance away from major cities around. The facilities are on average acceptable. The place is quiet and well suit for works requirement mental peace and isolation. Our staff there are most happy with it. It is, however, too distant for major cities that we have had great difficulties in recruiting people. People often prefers to work at locations near to their home. Even if you are willing to pay more, you can hardly get a few more people willing to come to work. Money can buy almost every thing but a few. Leisure time is of no doubt one of those. This is especially true when there are plenty of job supplies in the market like China.

So eventually we decided to move, for the sake of our long term growth. The place could be good setting up factories but surely not for a software house to which thoughtful labor is the most important asset we considered. It should be a good move, in theory. Yet Yogi Berr’s quote shows its power to me once again, “In theory there’s no difference between theory and practice. But, in practice, there is“. Our new office environment is shocking. God please forgive me this little nervous moron.

The new office is, um, by the road. It is not physically by the road. After all, it is an apartment 18 floors high from the ground. It’s right next to a busy road crossing. It’s not air-conditioned that we have to keep the windows and doors open maintain proper ventilation under a 33 degree temperature. We have lots of “fresh” air from road, with plenty of noise as bonus. Every minute you can feel clearly how many heavy vehicles has passed through the road below. As every time they do, doors and the floor shake. You can easily measure how hot the outdoor is by counting the frequency the drivers blow their horn. Definitely we are giving the term “labor intensive industry” a whole new face, packing 16 people in less than 800 square foot.

If ever this looks like I am making a complaint about the work place, sorry but yes I do, from the point of view of team productivity.

Weeks ago I read articles discussing factors affecting an office’s productivity. To dig out the key factors, the researchers carried out a game named “Coding War Game“. The rules are simple. A pair of developers from the same organization is chosen to perform the same piece of work. They work against each other. They do all the work from designing, coding, and testing according to the fixed specification with the same language and computers of identical configuration. When they are done, time and the result of acceptance tests are recorded.

There are tons of figures and findings produced by the game. I’m not going to list all but a few here:

• People in a noisy environment are more likely to produce more defects than those in a quiet environment do.
• Language, years of experience, salary surprisingly has little effect on productivity.
• Dedicated square foot per person matters. Well, it’s just a repeat of the first finding in terms of space. Noise level is always inversely proportional to space.

Put it this way. If some day I have my own kids, I just won’t let them do their homework in front of a TV. You might feel yourself like a code warrior on the road. But you end up spending most of your time fighting the defects you produced than critical business problem you are assigned to solve.

May be one of you would tell me that if you concentrate enough on your work, noise or heat does no harm to you. You are even becoming superior to the others cos you have proven your ability to live with a difficult environment. Right, when I was a kid, Mum used to tell me that if you have a peaceful mind you feel cool even under a hot sun. It’s true but not necessary. You can do it don’t mean you always have to. It comes at a cost. It consumes your concentration. You can spent the effort to other more valuable things than keeping yourself cool when you don’t have to. If I were a monk, I might not not care these at all putting myself into deep concentration thinking about life. But forgive me Buddha, I can’t earn pennies with a peaceful mind. I won’t like to hire a team of monk for making money either.

I still recalled the statement in book “Peopleware” talking about management. It said the manager’s function is not to make people work, but to make it possible for people to work. I agree this from the bottom of my heart. The first and biggest challenge ahead, as I soon realized when I stepped into the new “office”, is to build a better office.

I will seriously consider the idea of having a high quality headphone in our developers’ tool kit. At least one for myself

Every success starts with a dream right? See my dream, visually : )
P.S. Sell your ice-creams by the road, not your code please.

It’s not a easy job. Well, at least not as easy as what my XP book has shown me. It took me almost 5 hours to come up with the first processed list of user stories. When I finally sit back with a sign of relief, I begin to think: what’s standing in my way to get a set of nicely forged user stories?

User Stories Duplicates

Duplicates matters. Perhaps it is the way I ran the collection of user stories in my last workshop matters. I was running out of the 2 hour limit I set that I can only managed to tell every body wrote the stories down on their own then I collected them. There was no discussion at all and thus there no chance for me at all to try to remove the duplicates by utilizing the power of group. Some popular stories show themselves on the cards for 3 times or more. Lucky that I have only 47 cards I am still able to remove the duplicates properly. But I surely will goes into trouble of running out of memory if the number grows beyond a hundred.

Greedy Writing Style

If you are letting people do the writings on their own, you can never avoid people writing their wishes in a greedy way. I see bullets, arrows, slashes every few stories I read. A user writes to me as follows:

Implementation consultant
- Input network/system config.
- Edit/View assigned customer profile.
- Can edit/view only when the case is not closed.
- Get/download license.

If Santa ever let me write my only Christmas wish on a tiny note card, I will probably write:

• Wish 1a: A new car.
• Wish 1b: Sword of a thousand truth.
• Wish 1c: More wishes.

The story could has split into 4 smaller and more digestible stories.

Missing important business parts

Our application need to support our partners reselling products and services. But it is never clear that if in the presence of a reseller our application, or even our own company’s identity, should never be shown to the customers. This definition, however, makes a difference when its comes to serve and support the customer, and to handle the transaction flow between customer and the application. When I came to the stories, I was stuck.

Then I come up with some thoughts in mind on how to do it better next time:

Let your users discuss

Perhaps the best way to remove duplicates is to have every body check on their own if stories from the others matches those their own ones. People, on general, are good at memorizing their own stuff then those from the others. This should be highly effective during the user story workshop. Bringing in your users into the discussions do many other good as well. You might get insights into area of business you are not familiar with. When you sit down, digest and re-organize your user stories such information surely helps.

Always write in plain sentences

Writes in simple and plain sentences. No bullet point. No numbering. No slash. No arrows. No matter it is you or your user is writing, follow the strict rule. If you running into trouble of needing a big paragraph to describe your story, you should break it. If you are running into trouble that you must need some bullet points to describe your story, break it.

Last but not least, gathering the stories from your user is more or less just a start of the process. To understand more about the stories, it is worthwhile for you to try to rewrite them in your own words whenever you can afford the time.

Read a user story, write a user story. If something makes a different, it’s probably the truth behind the scene.

For long I’ve been interested in how a software projects, a business one, goes from its start to the end. There are plenty of books talking about methodologies but no one ever showed me the complete history of development of a real business software. May be it’s too boring at all. Or the folks writing those lengthy books have never put the theories into practice. Not sure if this is a good news to my company, I’ve got a chance to drive the development of a new application almost on my own behalf running with a entirely new team in China. I decided that the project contains no top business secret that my boss wouldn’t mind me writing down the story. After all, may be I can earn myself some penny by publishing the story to folks like me ever wondered about how a piece of successful software is given birth. So I start blogging about it.

The project is launched to build an application facilitating our customer relationship management process, with weighted focus on long term relationship management that happen after users have purchased our products/services. After a few weeks of study I decided to go XP for this project. The project is new, with lots of area not very well defined nor explored. Our development buddies, on the other hand, new on technology and product design. It could be best to take an iterative approach like XP to handle all these varying factors with a fizzy yet controllable manner. To be honest I was not having a very pleasant experience with my last XP project. Yet those big up-front methodologies make me more sick. Cockburn, the proposer of crystal clear methodology, said you should always review your process and shape it iteratively to make it work better especially your process is not giving what it’s supposed to give. Okay, I am sold. I don’t want to give up lessons learn from my last XP trial either. So I give it a second chance.

Projects always start with requirement gathering, no matter what methodology has been chosen to layout the project. I decided to talk to our users in terms of “User Story”. User story is plain, goal oriented and can be understand by everyone. It’s more valuable to know the goals that the buttons they want to have on their screen, or the number of fields they would like to have for describing a shipping address.

Today, 23th July 07, we have hold our first user story workshop, one of the best option to gather large number of user stories in a very short time. A few of the user representative from different teams and departments are invited. Our folks are busy. So I set the time limit to 2 hours. As the idea of working with user stories is still new to our folks, I spent around 10 minutes briefing them what’s user story and a user story workshop is about. We started with listing out roles. Then with the roles identified in mind we brainstormed the user stories the roles could have, writing each on a little note card.

Users were confused a bit at first what roles are to be identified. Say, role A wants to see something about B. Should B considered as a role as well? My answer is, no. Cos the application serves B in no way at all. The story should be written under the name of role A in fact. All right, then confusions gone and the list began to storm. They surprised me in numerous way I think the users want the application to be. Actually before I run the workshop I have made myself a list of roles and user stories given my understanding on the application’s problem domain. I can hardly think of variations of customer role but our users managed to give 10 customer roles just in minutes, though after a dicussion we managed to reduce the duplicates making the number down to 4. The user stores gathered thereafter surprised me as well in their variety. Most XP books would suggest you to get to your users. Sometimes if you are not able to get real users you have no choice but to get input from user proxy instead. Typical user proxy includes user’s manager, domain experts, development manager, marketing group, salespersons and former users. Yet these proxies, though all with their expertise related to the application’s usage, does give stories with bias. The bias could be so great that if you are unaware of it you could drap your application towards a very wrong direction. When I compared my own list with that gathered, I feel I’m lucky to have access to real users.

At the end of the day, I got a dozen of roles and user stories to start my next phase of work, to digest user stories and organize them into our upcoming project plan. No computer processing, only papers and hands. We done it all quickly with a whiteboard, a stack of note cards and pens. Things looks good. Our folks were enjoying it, at least it appeared to me as so when they were writing the stories with laugher on their faces. We have a clearer view on the goals and scope of the project. We have the atomsphere of conversation between development force and user force. And we are on the track.