FriendFeed developers, give us some love!

I like FriendFeed a lot. It has displaced FaceBook and my PS3 as the thing I do when I'm not doing anything. And there are new things happening on it all the time, so the developers are obviously hard at work. And they have a FriendFeed feedback room where people talk about the things they want, and they have bug submission forms, etc., etc.

But I've no idea whether the developers really pay attention to what people say in the room or the forms. Given the fix-it Fridays I guess they're looking at the bugs, but who drives the new features?

Well, it should be us, the users.

And this may be happening, but there's no way of telling.

I wrote previously about UserVoice, and I'm bringing it up again now because I think this is exactly what FriendFeed needs. I'll even give you the piccy again:

Let us tell you as a community what's important to us, and let us see what you're doing about it.

And of course if you managed to do some cool integration between the feedback room and the UserVoice page that'd be even sweeter - comments map to comments, likes map to votes, don't need to register separately and so on.

Go on, show us some love!

Reddit: The bookmarking site that won't let you bookmark

OK. This I just don't get:

All I was trying to do was post two bookmarks within about a minute of each other.

How does this make sense? Tell me, please.

Give me more social interop!

I'm sure most people by now are like me and have a proliferation of accounts across social media sites: Twitter, Digg, Blogger, FaceBook, WordPress, FriendFeed, MySpace - the list is endless.

Fairly recently I signed up on FriendFeed, which does an excellent job of bringing all these together into one place and allowing you to do interesting things with the combined social stream. The developers are really active improving integration with other sites (especially Twitter), respond to feedback from the community, plus they sometimes come out with things like SUP which have much broader implications.

But it's not perfect. And it's mainly not their fault.

My main beef at the moment is around what happens if someone posts something that people then comment on. Say for example that Robert Scoble posts something an interesting article on his blog, which will then automatically appear on FriendFeed. FriendFeed does an OK job of spotting when someone else shares it on something like Digg or Google Reader it so it appears in their feed as well - it marks it as a related article of the original post. But where do you comment on the entry - in FriendFeed or in the blog? If you do it in FriendFeed then anyone not also on FriendFeed and subscribed either to you or to the author will not see it. If you do it in the blog then the comment doesn't make it to FriendFeed. The author has to keep track of multiple separate discussion threads across the original blog site and FriendFeed.

Open it up everybody!

So everyone needs to stop playing the "my site is the one true site" thing and accept that there will always be n sites catering to different audiences, but with some severe overlap. Now we're all thinking straight, open up the APIs for commenting/retweeting. If I comment in FriendFeed it should be added to the blog entry (maybe this should be an option for the author when they add their feed to FriendFeed). If someone comments in the blog entry then it should appear in FriendFeed (again an option for the author) and if FriendFeed knows my ID on the blog/Twitter/whatever, then it should match this up so it appears in my activity stream in just the same way as if I'd commented directly in FriendFeed.

How hard can that be? I don't even think there are commercial arguments against it, as surely this would just drive extra traffic to the sites because there would be more interesting discussions.

So FriendFeed developers please come up with a cool API for doing this, then everyone else please implement it so we can bring it all together.

Update

Just spotted that when you comment in FriendFeed to someone else's Tweet then you have the option of also doing it as an @reply on Twitter. Good stuff - now what about the rest?

Update 2

It looks like using Disqus to manage your comments gives you some integration with FF, but I'm not sure yet if posting a reply in FF will come back as a comment...

Companies should take responsibility for their software

One of the problems with working in the IT industry is that you become tech support to anyone you know who's not in the IT industry (and some of those that are but shouldn't be). My mother-in-law is not in the IT industry and computers to her are a way to get things done rather holding any particular interest to her, so inevitable I spend some time helping her out with the odd issue or two.

Toward the end of last year she finally decided that the ancient desktop she had that was running Windows 98 ME really really was past it, so went out and bought a new Acer laptop which came preinstalled with Vista. So of course the odd issue or two came up. Living 200 miles away from your MiL is something that many people envy, but it does have the down-side that tech support trouble shooting usually involves the phone and her describing what's going on (or her interpretation of that) and me trying to figure out what's really happening and trying to fix it.

As I don't have any Vista-installed machines of my own then this was even more trouble than usual, so the next time we were down visiting I thought I'd just install MSN messenger and show her how to do the Remote Assistance thing. I could then see what was really happening and also take control to fix things rather than having to explain what click-and-drag was about.

But no. Messenger installation failed right at the end. Which I thought was a bit odd, even for Microsoft, as this was their latest OS, and their latest Messenger, and even they would have made sure this worked.

After a couple of retries to make sure I wasn't being totally dense, I hit Google, and sure enough other people were seeing the same problem, which turned out to be related to some Acer software that they had bundled on the laptop (which surely the European Commission would have something to say about). I was running out of time so didn't want to uninstall the Acer stuff, and so had to give up.

When we were back down over Christmas I had another look (as I'm a bit stubborn that way sometimes, and I know there are other options out there but this should have worked, damnit), and this time the MSN installer had some diagnosis that pointed to a patch from Acer (presumably as MS had had many people complaining about the same thing). It turns out that Acer have this thing called eDataSecurity which amongst other things hacks MSN messenger to encrypt file transfers across it. And the bad bit is that they hadn't kept it up to date with versions of Messenger, so this was preventing the installation working.

Fine, at least we now had a fix. So off I went to the Acer site to get the patch and the instructions at the time took me to an FTP directory listing:

Now forgive me if I'm wrong, but I would have thought that anyone non-technical at this point would have precisely zero chance of working out what to do next. Obviously I figured out to get the readme zip, extract the file, and then get the real installer that I wanted. But I consider this completely unacceptable that Acer found out they'd screwed up then thought this was an adequate solution for their average user.

To give them their due, they have now improved the page that this linked from, so the first step it now describes is:

Extract eDSMSN81patch.exe from the patch .rar file to an empty folder.

Like my mother-in-law is going to understand that. So they screwed up, realised that they screwed up their solution, then screwed up again. Nice going.

The good news is that the patch worked and I'm now fully remote-support-enabled, but two key messages for Acer and anyone else out there doing this kind of thing:

• If you're going to hack someone else's software then you'd better keep on top of it.
• Know your customer. Know what level of support they need. Know that if you screw up they are going to slag you off to everyone they meet.

I wasn't that keen on Acer before, but I can safely say that now I will never buy an Acer product. Ever.

How many software developers does it take to write good software?

Kirk’s had a couple recent rants against the use of Agile if you’re an excellent developer and I thought I’d comment on this, but realised that it’s part of a different question which is how big the ideal development team should be.

My answer is that it depends on the situation.

Types of developer

To explain my thinking, I’m going to start by loosely categorising developers into three archetypes: Production-Line, Regular and Alpha.

• Production-Line developers: These are the ones where it wasn’t obvious that programming was going to be their life-choice – they weren’t born with the “programming gene” but for one reason or another ended up doing it anyway. Typically, they will need a lot of guidance, and are used most effectively in environments where they have detailed requirements given to them, strong processes around the way they work, and a large QA/test facility to ensure that what they produce works properly.
• Regular developers: These get what programming is and enjoy doing it. They are quite happy to take loose requirements and work out what the client really means by them, use a bit of initiative and produce good quality software at a reasonable pace. The level of process and testing needed around them is lower than Production-line, but they like working in an environment where there are clear goals and a road-map to take them there.
• Alpha developers: These are the people who know that they are the best developer around, and are not afraid to remind you of this. They typically score quite highly on the AQ test and are likely to rub people up the wrong way - partly because they always know best, and partly because they’re usually right. Alpha developers tend to really get into a particular technology (Python, Erlang, lambdas, WPF, MapReduce whatever) and try to use it for everything until the next shiny toy comes along. Processes annoy them (“just slowing me down, yo”). Detailed requirements annoy them (“it’s quicker to write the code than a requirement doc”). Unnecessary testing annoys them (“my code doesn’t have bugs, bugs are for losers”). Not being able to use the latest toys annoys them (“you chose the wrong technology”). But if you want innovation in your organisations then this is where to look for it.

Effect on development team size

Using the three different types effectively results in quite different team sizes:

• Production-line: Your team size is typically quite large (e.g. 20+), and a large proportion of the team is focused around activities other than straight development (e.g. project management, QA/testing, business analysis).
• Regular developers: Team size for an effective team usually doesn’t get bigger than about 8 developers plus a PM and maybe a couple of people for QA and business analysis.
• Alpha developers: Ideal team size is two, or maybe three if they have a (good) history of working together. One Alpha on his own will run the risk of not staying focused and also not having anyone to argue with about technology choices. More than three and you’re in for a whole world of pain and minimal productivity as they spend all their time arguing rather than developing.

So which kind of team do you want? It sounds like Alphas are best, but you also have to take into account the kind of company that you’re working in. Larger more traditional organisations typically like to have a lot of controls and processes around things as this allows them to tick boxes on audit reports that are issued from so far up the hierarchy that there is no visibility of what actually happens on the ground. They also have little appetite for the introduction of many new technologies or techniques as these are perceived to introduce unnecessary risk. And these are precisely the things that would drive an Alpha nuts. Plus if you really do have to churn out a big system then you probably couldn’t get enough Alphas to work together to be able to achieve it.

The result is a reasonable correlation between type of organisation, risk appetite, and kind of developers. To give some examples from the Financial sector:

But what about Agile?

I’m differentiating here between little-a agile (unit tests, continuous integration, refactoring and so on) from big-A Agile (total buy-in, stand-up meetings, Product Owner at the planning meetings, a near-religious fervour in defending Agile and creating new believers).

A lot of the agile techniques are used across all three kinds of teams very effectively. But Agile itself in my experience only really works for the middle group.

Team sizes for Production Line are too large to use Agile effectively as it’s all about communication. In Scrum for example, it's recommended that the ideal time size is about seven, and if you get bigger than this you start breaking into sub-teams to bring you back to the ideal.

Try to get Alphas to do Scrum and they’ll see it as a total waste of time and probably quit (or just use work time to do some pet project whilst complaining to anyone within earshot).

But for Regular developers it does increase overall productivity and also give other benefits such as client visibility/ownership that are usually desirable. I’m not sure exactly why this is, but my guess would be that this kind of size is about right for the communication-boosting techniques that are introduced, and that this kind of developer is receptive to a lightweight process rather than the kind used for Production-Line.

This is just based on what I’ve seen, and I’m sure that there are many people out there that can give counter-examples of applying Agile to small or big teams, but was it really the right thing to do or did you lose more than you gained?

Conclusion

If you’re building a team, think hard about what kind of people you want in it and how many, based on what you have to deliver and also what kind of environment you’re in. And make sure your methodology fits your team.

Consumer software vendors: this is how you should do customer feedback

Recently I shelled out a massive £1.19 on the Nambu iPhone app. This isn't actually the subject of this post because the best thing I like about it is not the app itself, but how Nambu manage feedback from customers on bugs or feature requests: UserVoice. Here it is in action:

Anyone who's used Digg before will instantly recognise this, but the genius part from UserVoice is to produce something that's a cross between Digg and JIRA. Here are the key features about how it works:

• It appears as part of your normal web site (e.g. http://iphone.feedback.nambu.com/).
• It's very easy to search existing items and create new ones.
• Customers vote for things you want them to do using up to three votes per item out of their allocation of ten, and also comment on items.
• Customers can see what's new, what's hot, and if they want get an RSS feed of updates.
• The developers keep watch over the list, review items and schedule them for releases (so what we've really got here is an Agile Product Backlog driven by consensus across all clients).
• Customers can imediately see what's going on with an item - being reviewed, planned for a specific release - and the developers comment on which release a feature will go into.

I think this is a great approach. It brings the customers much closer to what's going on with the app and allows them to drive what's happening next (but limiting total votes to ten keeps them focused on the things that really matter to them). It allows the developers to see what it's worth putting their time into rather than having to use guesswork or "market research". It gives the customers somewhere they can see they're being listened to rather than having to use an e-mail support inbox black hole or ring a call centre of hold music tedium and disinterested operators. It's very 2.0. What more could you want?

Whilst this works very well for small applications, it would be interesting to see how this really does scale up for something like iTunes (UserVoice do have some big customers on their client list). It's also worth noting that JIRA has had a votes feature for years, but it just doesn't achieve what UserVoice have done.

So if you're a small software application vendor then you definitely should be looking at UserVoice and asking yourself whether you really want to listen to your customers or not.