Archive for August, 2006

Mickey, Daisy and Goofy do some marketing

I love his posts more and more …

In How to get people talking about your product, Erik Sink starts off with a discussion on how NOT to do marketing, and subsequently glides into a discussion on the most favourite version control systems.

In that part, he reveals why a particular version control got a great word-of-mouth and ended high on the ranking.

Worth reading!

More marketing on Gartenberg’s three laws of consumer electronics


Comments (1)

Trying out Windows Live Writer

Just now I’m trying a new program to create posts on my weblog: Windows Live Writer.

Erno, a former collegue of me whose blog is still on my reading list, wrote about it while being on holidays.

Leave a Comment

Combining agile and offshore development

In optimizing processes IT organizations turned to offshore development OR to agile development, but not both.

That seems logical, as offshoring means no developer/customer interaction (whereas agile means intense interaction) and offshoring means heavy documentation (whereas agile means light documentation).

Surprisingly, the two can be combined successfully. 

Martin Fowler made a trip to India and came back with useful tips on agile offshore development.

Matt Simons describes problems and benefits of agile approaches in offshore situations:

  1. The Challenges of Offshore Development
  2. How Agile Concepts Make Offshore Harder
  3. How Agile Concepts Make Offshore Easier
  4. How to Succeed at Offshore Agile Development
  5. Is it Worth the Effort?

Leave a Comment

Often forgotten tips for better writing

Rich Chiesser describes Eight uncommon tips to improve your writing.

He describe these tips as uncommon not because they are rare or unique, but because they are so infrequently used that when he sees them employed it is a refreshing and rather uncommon occurrence.

The eight tips are:

  1. Match Style to Intent
  2. Outlining
  3. Story Boarding
  4. Match Tone and Detail to Audience
  5. Echo Some Words and Phrases
  6. Active Voice
  7. Grammar
  8. Proof Reading

Indeed, these are very commonsense tips, I added some detail from my own experience and from an internal memo I received some fifteen years ago:

  1. Match Style to Intent
    1.1 For what purpose is the text written?
    1.2 For whom is the text written?
    1.3 To what questions gives the text answers?
    1.4 What are the results, recommendations, conclusions?
    1.5 Why is the text written?
    1.6 What was the assignment?
    1.7 Why is the text written in this way and this order?
  2. Outlining
    2.1 Is the division into chapters clear?
    2.2 Is there a logical sequence in the chapters?
    2.3 Is the subdivision in paragraphs clear?
    2.4 Is there a logical sequence in the paragraphs?
  3. Story Boarding
    3.1 Are the relations between chapters and paragraphs clear?
    3.2 What is meant by the title?
  4. Match Tone and Detail to Audience
    4.1 Do you connect at the foreknowledge of the reader?
    4.2 Is the text suitable for the reader?
    4.3 Is the amount of explanation sufficient?
    4.4 Do you give precisely enough details, or too much or too little?
    4.5 What is the importance of the text to the reader?
  5. Echo Some Words and Phrases
    5.1 Restate the assignment, to emphasize you are really doing what is asked for. 
  6. Active Voice
  7. Grammar
  8. Proof Reading
    8.1 Is the text free of contradictions?
    8.2 Are the conclusions based on facts?
    8.3 Are the arguements for and against the recommendations given?
    8.4 Why are some subjects mentioned, and others not?

Leave a Comment

Users stuck in permanent beginner mode

 Kathy Sierra on users stuck in permanent beginner mode. And that’s more of a design problem than a users problem. Very interesting to read, read the comments (*a lot*) too!

Leave a Comment

Handling feature-creep on your NEXT RELEASE

Next release ...In an interesting post on changing the way his company (37signals) is managing the naming of new versions, David explains they left the habit of numbering from version 2.1 to 2.2, and instead name the versions after the biggest common feature the new version delivers.

So if the next version is all about improved security, the release is simply called the “improved security release”.

This clear naming convention helps David to decide what’s in the next release, and what’s not.

The post was noticed at Tyner Blain, who devoted an enthousiastic post on the subject.

Actually, the convention fits nicely in the way releases should be handled within RUP. For every release a problem statement and a product position statement are developed AND agreed upon between all stakeholders of the project.

The problem statement is a solution-neutral summary of the stakeholders’ shared understanding of the problem to be solved.
The product position statement is the “mission statement” for the system to be built (the solution). The product position statement is a vehicle for communicating a brief definition of the system to all stakeholders (definitions from safari).

The problem statement and the product position statement are excellent tools to use in the CCB  (Change & Control Board) who decides on including or excluding new features in the (next) release. Both statements are documented in the RUP Vision document.

If you have a hard time defining these statements, you will definitely have a hard time with scope-creep. Now you see why!

Comments (2)

NO! – Bad User!!!

Leave a Comment

Older Posts »