ia play

Whilst thinking about AI, I went on a bit of a Wikipedia wander and discovered:

• android is technically masculine. You can also have gynoid.
• there’s a theory called “uncanny valley” that when robots look/act almost like actual humans, it causes revulsion in the human observers
• grey goo is an end of the world scenario in which out-of-control robots consume all matter while building more of themselves—a scenario known as ecophagy (“eating the environment”)

I’m sure that will all come in handy one day.

I listened to the Gardeners Question Time GM debate recently. Afterwards I tried to explain to PW why anti-GM protesters annoy me, when I mostly agree that turning propagation into something controlled by corporations is a bad thing.

I suppose I get annoyed with the focus on GM as the science that will destroy the world. Pretty much any technology has that capability but we only seem to be allowed to worry about one at a time (fretting about nuclear is very last century, it seems).

Co-incidently I’ve just finished Dan Simmon’s Hyperion series (tetralogy? cantos?) which features sinister artificial intelligence that may be intent on genocide. The AI takeover of the world (AI apocalypse, Cybernetic revolt, Machine Rule, Grey Goo) is such a common theme in modern Sci-Fi that it seems curious that there has not yet been tabloid outrage at the reckless scientists working in the field of AI. Think Matrix, Terminator, Battlestar Galactica, and 2001. And after all, what’s is the etymology of ‘Frankenstein Foods’?

Perhaps it is just a little too early.

(I’m also regularly referred to as the AI, as in “we’ll get the AI to knock out some wireframes”, so I’m looking forward to being mistaken for a tabloid threat to humanity)

We did a lot of Agile projects at the BBC, as a general rule it was a style enthused about by the developers and grumbled about by the designers. I had good experiences and bad and to be honest most of the bad were where the project was called Agile but was really nothing of the sort.

My current headaches with Agile are different, and mostly come down to the client-supplier situation:

Lack of co-location
Essentially the developers are in one office and all the decision makers are in another. Questions are often saved up for face-to-face meetings rather asked at the right time to prevent wasted development. Face-to-face conversations are too rare and are often replaced by easily misinterpreted email debates.

Developers aren’t the only pigs
(http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig)
There are plenty of other people are producing vital deliverables. The methodology needs to manage them too but if those people are off-site and employed by a different company (even if that is the customer) then it is easy for their work to be less closely managed.

Confident Agile leadership
Most projects I’ve been in have involved a significant number of Agile newbies. Usually this hasn’t been a problem as there has been a strong, experienced Agile advocate. With a client-supplier relationship there needs to be an advocate on both sides. In the absence of an experienced advocate, all problems will be assumed to be the fault of the method.

Shared ownership
With a supplier involved it creates a barrier between team members. Prioritisation decisions are left to the product owner rather than being made by a team of experts (or at least on the recommendation of a team of experts).  It is too easy for the supplier to leave tricky decisions to the customer, who doesn’t always understand the consequences of the decisions.

The financial bottom-line
I’m not an expert on contracts but the wrong choice of contract can damage the choice of Agile as a methodology. For some more informed thoughts about contract choice try:
http://alistair.cockburn.us/Agile+contracts
http://www.poppendieck.com/pdfs/AgileContracts.pdf

I’m trying to tackle the first two points, as they seem to be the most within my control. We may be able to repair some of the damage to the project but I fear it may be too late to rescue Agile’s reputation within the organisation.

My colleagues and I are getting chided for not having put Christmas decorations on our bank of desks. I sit with the finance team at the moment and some have suggested the absence of Christmas cheer reflects on our personalities.

Personally I’m just a traditions pedant. Decorations are for Yuletide/Twelvetide not Advent. They go up on Xmas eve and come down on Twelfth Night (perhaps under the eye of the Lord of Misrule?).

Just as it is bad luck to leave them up after that, it is bad luck to bring evergreen decorations into the house earlier. I suppose technically you could get away with tinsel but not the tree.

In spite of PW’s new career choice, we’re not getting a Christmas tree (although he might swipe us some mistletoe). I’m going to bring a potted twisted hazel in and hang some baubles on it.

(random Christmas related fact: today is Poinsettia Day)

We’re working on SharePoint teamsite requirements today. Team-sites are permission controlled “collaboration spaces”.

We’re using them for three types of teams:

• formal organisational teams i.e. teams that share a line manager
• project teams, that might be within an organisational team or cross-team
• network teams, for communities of practice

Because of the accessibility changes required, all functionality requires development so it isn’t the case that we can just stick functionality in and see if people use it.

We’re planning to include content pages, document libraries, search functionality, discussion boards, lists and alerts. We’re not including calenders, wikis and blogs. With calenders we don’t think they’re particularly useful when they don’t integrate elegantly with Outlook- we’re told you can’t send an Outlook appointment to a SharePoint calendar. Wikis are not widely used within the organisation and would require an awareness/training effort so they’re out for now. Blogs are similarly not a common tool at present, and I don’t buy the scenario of blogging for a very limited team audience.

I’ve been researching the reasons for not moving everything from your shared drives to SharePoint. These seemed to be the common factors mentioned (with varying levels of explanation/justification):

1. Storage costs
“SQL Server storage is more expensive and complicated than network storage” -objectmix.com

2. Archives
“The basic collaborative nature of  Sharepoint probably doesn’t support long term historical archives of data.” -objectmix.com

3. Security

4. Backup and restore issues

5. Types of files
File types not to store in SharePoint: scripts, executables, multi files, CIFS links, some access databases, Outlook Personal Folders, Application files (*.exe, *.dll, *.bat, *.log, etc.), large backup files (> 50 MB *.zip, *.iso, *.bak, etc.),DVD images (*.ifo, *.vob).

6. File usage
Usage reasons not to store in SharePoint: files not accessed for months and files without collaborative value

7. Size of files
File size restrictions seems to be the most commonly mentioned point, with most sources suggesting an upper limit of 50-100MB per file.

To maintain optimum server performance and ease navigation of the document libraries and folder structures, use the following guidelines as the upper limits when organizing your files:

 o   1,000 files in a folder

o   1,000 folders per Document Library

o   1,000 document libraries per site

o   50 megabytes (MB) per file”

- tributarysoft.wordpress.com

8. Linked documents
“Linked documents and files cannot be run from a SharePoint site, as the dependency on an external sources isn’t captured in SharePoint.”
- blogs.msdn.com/joelo/

9. Only in SharePoint for search purposes
The files in the drives can still be searched for in SharePoint. “Just index them with Microsoft Office SharePoint Server and they will become discoverable as well.”
- jopx.blogspot.com/

Sources:
http://objectmix.com/sharepoint/337243-sharepoint-replace-network-shared-drives.html
http://blogs.msdn.com/joelo/archive/2007/11/08/what-not-to-store-in-sharepoint.aspx
http://tributarysoft.wordpress.com/2008/08/18/windows-file-share-migration-to-sharepoint-nyc/
http://blogs.msdn.com/mikewat/archive/2006/12/09/file-shares-vs-sharepoint.aspx
http://jopx.blogspot.com/2007/01/sharepoint-document-libraries-or-is.html