This looks very interesting, although it is at an early stage right now. A system for building and managing cloud-hosted applications, using XMPP as a communication subsystem.
InfoQ: Engine Yard Releases Cloud Management Framework Vertebra
I have just listened to an excellent podcast interview with Andy Singleton from Assembla in which the discussion ranges around his extreme views on how to run highly productive distributed software teams.
Top tips include “don’t interview when hiring”, “don’t estimate work”, “don’t do conference calls”, etc… Contentious, but very well explained and justified. This podcast is so packed with thoughtful stuff that I’m sure I’ll listen to it again.
Interesting post about the different usage and expectations of mobile search and general search. In short, location matters.
ShareMe -The Mobile Future : Mobile Search is Not GOOGLE SEARCH
Twitter is all over the media these days. It was a top topic of conversation in the pub last night. It’s interesting to see it developing from a toy into a useful communication “platform”.
Twitter Fast Growing Beyond Its Messaging Roots | Epicenter from Wired.com.
Recently I have found myself getting quite cross with articles published by the British Computer Society (BCS), but at least they can provide interesting and useful stuff sometimes.
Here are some transcripts of presentations about starting companies and venture capital in the UK, together with a summary of some discussions.
The road to riches begins at the water cooler : Articles : Business IT Interface : BCS
Just a shame that this was not an open conference, though.
1. Remember to breathe. You’ve probably worked for two years to get to this moment, and there’s no guarantee you’ll ever get to do it again. You might as well enjoy it.
2. The computer is a Buddha. It sees the world as it is and does exactly what you tell it. It doesn’t implement your expectations or your fantasies. Try to see as the computer sees.
3. No design survives contact with the users. Research, analyse, test and prepare. Then be ready to throw it all away when real users don’t do it like that.
4. A good idea can come from anywhere. You might as well listen to what others have to say because you’re going to get the credit (and blame) anyway. Your programmers, salesmen, accountants, admin folks, project managers, cleaners and so on have probably used a wider range of software than you have even heard of. Joel Spolsky calls this “hallway usability testing”
5. Life is messy. It doesn’t stop while you’re talking on the telephone. If it feels too comfortable, it’s probably wrong; if it feels right it’s probably too slow.
6. No software can ever be simple enough. Surgeons, cops and priests have a lot on their minds, but they still need your software to work right.
7. A user’s attention span is even shorter than yours. Give them something useful, valuable, compelling and obvious everywhere, all the time. As Steve Krug puts it, “Don’t make me think”!
8. The users define the software, the software doesn’t define the users. Unless you have a style, don’t act as if you do.
9. Make your software for one person at a time. Imagine your fourth grade teacher sitting alone in the dark.
10. Where there is no solution there is no problem. At some point in every project, the company management loses faith in the product and the employees loses faith in the company management. Somehow it all works out.
If you are more interested in making movies, see the original at: Ed Zwick’s Golden Moviemaking Rules | MovieMaker Magazine.
In my dark moments I worry about the security of cloud computing. I used to be pretty upbeat about security, until some servers I was using to run a small specialist java hosting business were hacked. This resulted in the collapse of that business and the loss of several customer sites. Since then I have been painfully aware of the need to keep any public system scrupulously up-to-date with security patches and suchlike.
My security worries give me concerns about launching a business based on Amazon’s EC2, as I cannot see at the moment how the fiddly details of keeping the virtual system images patched an up to date will happen. Please feel free to reassure me!
When I read the title of this article from the Java Developer’s Journal, this was my immediate thought. The article does not address this particular issue, but instead covers some of the problems of protecting data in transit between distributed systems.
This article really helps join the dots for a project I’m thinking about a lot at the moment.
Connecting Apple’s iPhone to Google’s cloud computing offerings.
Jason Yip from Thoughtworks has a nice summary of points to remember when organising or managing stand-up meetings.
Most agile teams use “stories” for agile planning, but there’s still some confusion as to what a story really is. This becomes a particular problem when a team is asked to estimate some grand feature which takes one bullet point on a marketing slide but might take several iterations to implement.
It can be tempting to fall back on traditional project management techniques and start a process of eliciting “requirements”, then splitting the big story into a slew of sub-components and tasks (all mandatory, of course) with a rippling gantt chart of dependencies and timescale. For an agile project, though, this is the “dark side”. and can easily distort the rest of the development and delivery process beyond all recognition.
What we need is a more agile way of digesting such large chunks of work and somehow turning the a single big “must have” into an iterative, evolutionary, adaptive prioritisation.
Marty Haught has some thoughts and suggstions on this topic (Handling Large Stories in Agile) but it seems to me that the core solution is to remember that the project as a whole is essentially just a large story, and so the large story may be approached in exactly the same way.
This is an important, but under-emphasised, aspect of an agile process. It is “fractal” and “self similar” in that it should have the same fundamental structure regardless of the level at which it is viewed.
For years Frank Carver has been paying attention to the strange world of convergent technology. During that time he has discussed and researched broad subject areas, come to some surprising conclusions, produced and distributed digital media, scattered ideas and opinions like sparks from a firework, and above all consulted for businesses both large and small to help develop and deploy successful systems, services, and products in this highly complex arena.
