Twitter is like an AK-47

There seems to be social networks for every conceivable thing springing up everywhere, from location with your interstate-trip based DOPPLR and Brightkite for daily use, and then there’s ones just for keeping in touch with friends like Facebook and FriendFeed and Twine for common interests, YouTube for videos down to your specialised networks like Project Vino and many more … many of them great sites that really facilitate the social aspect of communication and collaboration around a particular thing.

But Twitter … Twitter is like an AK-47.

The first model of the AK-47 was designed back in 1947 (hence the “47″ part of the name of the gun) by Mikhail Kalashnikov. It was designed to be cheap and easy to produce, easy to clean, reliable and able to operate even if dirt or snow got into the moving parts of the assault rifle. One of the downsides of meeting these requirements was that the gun was inaccurate - but given the way the gun was designed and the manner it was expected to be deployed in battle meant this wasn’t a problem.

Twitter has no real focus and is really quite basic. There is no specified topic, rules or even etiquette. Anything goes. And that is why I believe Twitter has been so successful and popular. It provides a basic framework for social interaction without promising any special functionality or requiring the user to follow a certain procedure for using the system or adhering to a certain topic like many other specialised social networks do.

Sure, there might be sites that allow users to rate and comment on films … but you can ask on Twitter what the best movies are out at the moment. You can log your trips into DOPPLR if you want … but you can just post on Twitter where you’re off to, and it’s not out of place. Product reviews, foods, technology - Twitter can take all of them in its stride. I think the number of tools, applications, search engines etc that hook into the Twitter API are a testament to it’s flexibility.

Unfortunately the one attribute of the AK-47 which Twitter has yet to adopt is ruggedness. It really does have to stop falling over.

Tags: , ,

Be the first to comment

Stolen laptop

A friend of mines Toshiba M200 tablet PC was taken from their vehicle after the rear window was smashed last night (Friday 16 May) in Braddon, Canberra.

If you see a tablet laptop (it’s a laptop with a screen you can swivel around and use as a touch screen instead of with the keyboard) around Canberra that doesn’t belong to the owner (ie no proof of ownership or purchase or they don’t know anything about it) that they’re trying to sell then please contact me or Crime Stoppers on 1800 333 000.

UPDATE: More info over at Canberra Craigslist

Tags: , , , , , , , , , , ,

1 Comment

Working in an IT outpost: The diary of an outlaw

After a comment I made in a tweet the other evening regarding IT departments it reminded me of something I’d been wanting to blog about for a while. Although a lot of what I do is technical in nature and many people assume is IT … I’ve never actually worked in the IT department of an organisation or government department … except maybe for a short while at Catalyst Interactive when starting my career 7 years ago before I decided I wasn’t interested in swapping backup tapes and switching toners in printers.

But there’s always been a strong link with IT because of the technical nature of design and development and the requirement for development and testing environments, web servers, admin access to systems, third party applications and tools etc - which means that the areas I’ve worked in aren’t quite IT but necessarily outside of the standard operating environment of most other staff in an organisation.

It’s like working in an IT outpost where we are a technology area embedded within a business area such as a specific outcome of an organisation or government department or within a business-focussed information and communications area. We work outside the procedures of IT because we’re not IT yet we need to interface with IT’s procedures which often are not quite relevant to the work we do or in some cases are made up on the fly because IT omits to accommodate our area into their planning and procedure development.

The result? Because there’s no defined interaction protocols between ourselves and IT it all works around building a good relationship with key personnel in IT and then asking for favours and hoping everyone is in a good mood that day. It’s not impossible - I’ve made it work in the past and it takes a lot of effort but the end result is that you can get things happening that sometimes even other sub-teams within IT couldn’t make happen because procedure explicitly disallows it - but our unique position necessitates exceptions unless of course it relates to things like IT Security in which case there are no compromises.

It’s both a position of freedom and flexibility and of responsible utilisation of that trust relationship with the main IT area which ultimately has control of the servers and the networks … though I did at one stage have a test and staging server for a system under my desk because it wasn’t IT’s responsibility to maintain the infrastructure for that system; but cases of needing to run mini-IT infrastructure yourself are rare and generally not a good idea - even if you also hire a database administrator, security expert and network administrator into your team. Apart from the fact that IT will not like it that fact is you will never be able to set up the necessary infrastructure to do it properly and at best it’ll be an ad hoc half-back installation that OH&S will scream at when they walk into your office and see blue CAT5 cable running along the floor with servers sitting on desks cooled by an exhaust fan that’s been pulled out of the roof and placed next to them …

Is it a good way of working? Well - perhaps in some cases a formal MoU would help ensure that we at least got some sort of assistance and cooperation when needed and guarantee the IT staff responsible for the security and reliability of the network that we’re not going to allow n00bs to break anything or introduce risks … but as long as you’re open to a bit of negotiation and relationship-building with various people in IT who can help you get the thing you need so you can do your job then it works out in the end.

The only problem is when someone gets wind of something you want done and shuts it down for whatever reason. When IT wants to say no to something then that’s pretty much the end of it unless you go over their head … which is something you’ll have to decide on a case by case basis; whether it’s worth it (think a Red Storm Rising style escalation) or pick your battles.

Any other stories of people who’s worked in similar situations and teams?

Tags: , , , ,

2 Comments

National Broadband Network

Some thoughts on the National Broadband Network included in the recently released Federal Budget.

Tags: , , , , , , ,

Be the first to comment

Common project and program management failures

The UK Identity & Passport Service (IPS) has released a post-implementation report with lessons learned from five key projects undertaken in 2007. According to Michael Krigsman the recommendations from this report contain many common failure points for project and program management:

  • Benefits Realisation
  • Business Involvement
  • Communication
  • Contract Management
  • Culture
  • Governance
  • Implementation Roles and Responsibilities
  • Issues management
  • Management of External Communications
  • Off-system Customer Experience Testing (CET)
  • Phased Implementation and Transition Plan
  • Process
  • Project Approach
  • Project Resourcing
  • Release Authority Board (RAB)
  • Release Authority and Business Readiness Meetings
  • Security Accreditation
  • Staff Recruitment
  • Stakeholder Management
  • Testing Environment
  • Testing Methodology
  • Testing and Piloting

The full article by Michael Krigsman on ZDNet: UK gov’t releases transparent post-failure analysis

Tags: , , , , , , , ,

1 Comment