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
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.
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:
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:
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:
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!
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!
I wrote before on being tired of waiting for Adobe Acrobat Reader to load.
Recently I got so tired of downloading updates for Acrobat (and having to reboot everytime …) that I decided to deinstall Acrobat Reader and changed to Foxit Reader.
It works a lot faster than Acrobat, although some “exotic” features might not work right now.
The only drawback I found out is that I have to get used to the new icon, I really got used to Acrobat’s one!
On one of my previous projects we organized daily stand-up meetings, where everybody gathered together at 09:00. In turn everybody said what they did yesterday, what the planned to do today and whether anything was hindering them to make progress.
After a while, it appeared that some people had something to say every day (and some had a lot to say) and others never had anything interesting to share. Somehow, the stand-up meeting was not working.
Jason Yip published a comprehensive post about stand-up meetings, and discusses a number of “patterns” used. Perhaps we should have looked into the “Pigs-and-Chickens” pattern before…
James ShoreMore wrote a chapter on stand-up meetings in his book The Art of Agile Development. Some chapters of the book are available as preview
Joe Stagner presents some solutions for file downloading, other than providing a link to af file location. These other solutions are interesting if:
