- Posted by liammclennan on May 20, 2009
Every project needs an efficient way to record and share information. My favourite is a project wiki. Wikipedia defines Wiki as:
A wiki is a collection of Web pages designed to enable anyone with access to contribute or modify content, using a simplified markup language. Wikis are often used to create collaborative websites and to power community websites.
Instiki is a simple wiki engine developed by the people behind Ruby on Rails. Not suprisingly, it runs on ruby on rails. Instiki's strengths are that it is easy to install and easy to use. It is not a enterprise class wiki, however I find that simplicity is often better. One thing that does bug me about instiki is the installation instructions:
Windows
-
Download
-
run “instiki.cmd” with Ruby 1.8.4 or greater installed (get One-Click Ruby Installer for Windows)
-
Chuckle… There Is No Step Three™! :) (See note)
Apparently installing ruby is not a step in the installation process. Using the same technique it turns out that screwturn wiki has only one installation step:
Deploy the Wiki's files into your production ASP.NET server, being sure that the ASP.NET runtime has write permissions for the public\ directory (Setup your Wiki configuration by editing the Web.config file (Download the ScrewTurn Wiki site-only package and extract it on your hard disk ))
Appart from that instiki is a wonderful tool. It supports revisions, RSS, authors, search, multiple webs, password protected webs and a number of other features. On windows it will run as a console application by default, which is clearly not desirable. The instructions to convert it to a windows service are scary but easy to follow.
If you looking for a simple wiki tool consider Instiki.
- Posted by liammclennan on February 21, 2009
I like working with smaller organisations. The work is more interesting and I have more opportunities to make a difference. But there is a down side. Small companies tend to be short of cash and experience. Their lack of experience means that they rarely give their projects to quality development organisations. They have to fail a few times first, in what I am dubbing "the classic project death spiral". It goes like this:
1. Joe's Cheesburger shop decides to embark upon a software project. They will commission an ebay clone with a twitter style messaging system built-in. They can barely contain their excitement. They have never been involved with a software development project before, but it's a lot like making a cheeseburger. Joe, the director, is confident of his 'gut feel' that the work should not cost more than $10,000.
2. Joe's want to do things right, so they take their idea to Macrosoft, a reputable development firm. Macrosoft come back with an estimate of $250,000. Joe is outraged at Macrosoft's arrogance and lack of estimation skills.
3. It does not take long for Joe to find a local company that will take the job for $10,000. Exactly what Joe figured. He is pleased with his powers of perfect estimation. However, by this time Joe has had an even better idea. He will pull together a virtual team of developers and complete the project for $5,000!
4. The overseas teams starts well. Within days they have 90% of the screens almost completed (everything works except for the buttons). Joe is so excited that he tells all his friends.
5. Six months later things have declined. Progress is almost non-existant. Joe can't understand it. All they had to do was hook up a few buttons. The project has exceeded the original $10,000 budget and it is starting to feel like the money has been wasted. Reluctantly, Joe cancels the project. He gets a copy of the work that has been completed, so at least it's not a total loss. Joe is angry and has come to the conclusion that software developers are crafty, incompetent little thieves.
6. Friday after work Joe stops buy his sisters house to chat to Richard, his nephew. Richard is a computer wiz kid. Joe gives Richard the work that was completed by the virtual team and leaves; confident that the whole mess will be sorted out in a few weeks.
7. Richard turns out to be as crafty and incompetent as the virtual team. He keeps complaining that the code (whatever that is) is bad and says that he would be better off starting from scratch. Joe can't believe it!
At this point there are two possible outcome: Joe cancels the project completely or Joe realizes that paying penuts gets monkeys and gives the job to Macrosoft.
The scenario described above occurs because customers with no experience developing software (that's not their fault) try to treate software like a commodity. They hire the cheapest provider without regard to their skill or experience because they don't realise that making software is hard.
If you are thinking of starting a software project, think deeply about the people you give it to. Success is not guaranteed (in fact it is statistically unlikely) and a quality team is the only thing standing between your project and abject failure.