03.23.06
by

Liveblogging Multimedia Meets Radio & TV

Welcome to Geneva. I’m speaking tomorrow at the European Broadcasting Union’s Multimedia Meets Radio conference.

I feel like I’m at a meeting of the UN. They have little headphones so I can listen in English in case my Finnish is a bit rusty or non-existent in this case.

My biggest exposure to Finnish was the fake credits in Monty Python and the Holy Grail.

It makes me want to go all Khruschev and bang my shoe on the table, but I stayed up too late working on my presentation to get thrown out that quickly.

Michael Mullane, who invited me to take part is also liveblogging here.

That leaves me free to live blog today.

I’m really keen to understand how other broadcasters bridge the cultural and logistical divides between their new media teams and their brodcast teams. That’s a huge challenge. Different deadlines, different working practices and different attitudes towards innovation.

And I want to know how they are tailoring content for different platforms. How do you balance the unique opportunities on each platform while balancing it with the limited time and resources?

03.15.06
by

Doing less

Two years ago, when I first said I was going to become a ‘blog consultant’, many people laughed. “You’ll never make a living out of that,” they said. “Who is going to need you to teach them how to blog? I mean, come on. It’s easy.”

Deep down, I worried that they may be right. Who needs to be taught to use a blog? Who needs to be taught about the cultural differences between mainstream media and PR, and blogging? Who needs to know how to use wikis or instant messenger? Come on… it’s as easy as pie.

Two years ago, I spent a lot of time reading blogs, following all the main players, and writing about it all on Chocolate and Vodka or, later, here on Strange Attractor. Dave Sifry couldn’t fart without me knowing about it and blogging about it. As new blogging and social networking tools crawled into beta, I was there, ripping them into small bits if they were rubbish, exhorting you to go and play with them if they were good.

It was great. I got into some fantastic conversations with some really intelligent people, and those conversations frequently let me to conferences, seminars, and even just plain ol’ meet-ups (which are, usually, a lot more fun). I felt like I was a part of a community, a part of something bigger than me, and that my life was enhanced because of it.

Now, things are different. I am successful as a social software consultant – my diary is full for the immediate future, I have the stable income I didn’t have two years ago, and I have an awful lot more experience under my belt.

What I don’t have is time. Time to read blogs. Time to investigate new tools. Time to write. Time to be a part of the community of metabloggers whom I count as my peers. I feel a bit like I have slipped down the rabbit hole into an alternate reality in which Suw Charman works away at her desk every second of the day, hardly speaking to anyone (not even her friends), overwhelmed by email, and feeling guilty that she’s not crossing enough off her To Do list.

I don’t like this reality. I don’t like the fact that both Strange and CnV have suffered from my lack of time to post. (Note: I really should be replying to emails right now, instead of writing this, but people are just going to have to learn to wait.) And I really don’t like the feeling that I have drifted away from my community.

Feast or famine is a familiar cycle for any consultant, and in the nine years I have been working for myself, it’s been a cycle that I’ve come to understand at a very fundamental level. Until now, it’s been a financial cycle – you have a client, so you work your ass off for that client, and then when that contract ends you have nothing to replace it with because you were so busy working your ass off that you didn’t have time to go off and find another client. Blogging kills that cycle because I have a permanent presence on the net, even if it’s not as active as I would like. I have a load of leads for new clients to follow up, and I can’t imagine running out of work any time soon.

But the feast/famine cycle remains – except now it is all about time. I’m suffering a chronic time famine at the moment. Every second of every hour is filled with things I need to be doing, so all of the stuff that I want to do but which doesn’t have a deadline gets bumped, day after day after day. My To Do list has been moved to an A4 notebook, and it does nothing but get longer. Currently, it’s six pages of A4, and I know that I haven’t yet put everything on it. I would estimate that it should be at least triple that, if I honestly wrote down everything I want to or have to do.

I bought Getting Things Done, because I hoped it would help me get things done, but so far I’ve only had time to read the first 45 pages, and most of that was telling me to do things that I already do, or which I’ve tried before but which didn’t work. My conclusion is that the answer really isn’t about becoming more efficient (although patently that can’t hurt).

So what is the answer? On a fundamental level, the answer is ‘Do Less’. For months I’ve been saying it in jest, “I need to do less so that I can do more”, but it’s really very true. If I want to learn Spanish, if I want to take up climbing again, if I want to play my guitar then I need to free up some time in order to do those things, and in order to do that, I need to do less of all the other stuff.

Perhaps there’s a self-help book in there somewhere. Getting Less Stuff Done. Hmm, I think I’ll need to put that one on my To Do list.

03.05.06
by

An adoption strategy for social software in enterprise

Experience has shown that simply installing a wiki or blog (referred to collectively as ‘social software’) and making it available to users is not enough to encourage widespread adoption. Instead, active steps need to be taken to both foster use amongst key members of the community and to provide easily accessible support.

There are two ways to go about encouraging adoption of social software: fostering grassroots behaviours which develop organically from the bottom-up; or via top-down instruction. In general, the former is more desirable, as it will become self-sustaining over time – people become convinced of the tools’ usefulness, demonstrate that to colleagues, and help develop usage in an ad hoc, social way in line with their actual needs.

Top-down instruction may seem more appropriate in some environments, but may not be effective in the long-term as if the team leader stops actively making subordinates use the software, they may naturally give up if they have not become convinced of its usefulness. Bottom-up adoption taps into social incentives for contribution and fosters a culture of working openly that has greater strategic benefits. Inevitably in a successful deployment, top-down and bottom-up align themselves in what Ross Mayfield calls ‘middlespace‘.

Fostering grassroots adoption

This approach centres around identifying users who would clearly benefit from the new software, helping them to understand how it could help, and progressing their usage so that they can realise those benefits. These key users should:

  • be open to trying new software
  • be influential amongst their peers, thus able to help promulgate usage
  • have the support of their managers

Users who are potential evangelists should be identified at every level of management, not just amongst the higher echelons, or amongst the workforce.

1. Identify key user groups

The first step is to identify which potential user groups within the company could most benefit from using social software.

  • What needs do these people share?
  • What are their day-to-day aims?
  • What projects are they working on together?
  • What information flows between them, and how?

2. Identify and understand key users

Once you have identified key user groups, you need to know which users within that group are both influential and likely to be enthusiastic. Then consider how social software fits in to the context of their job, their daily working processes and the wider context of their group’s goals.

  • What specific problems does social software solve?
  • What are the benefits for this person?
  • How can the software be simply integrated into their existing working processes?
  • How does social software lower their work load, or the cognitive load associated with doing specific tasks?

Ideally, key users will be ‘supernodes’ – highly connected, in contact with a lot of people on a daily basis, and heavily involved with the function of their department and the transfer of information within the group and between groups. This may not be the group executive, but could well be his PA or a direct report. Frequently, people’s supernode status is not reflected by official hierarchy.

UPDATE: I don’t believe that supernodes are key anymore. I do believe that oft-ignored groups who are not traditionally thought of as influential, such as PAs, can in sometimes be crucial to an adoption strategy. But it’s far more important to focus on groups who share aims, actions, and information and who show existing enthusiasm for change and learning new stuff. This post explains in more detail why I changed my mind.

3. Convert key users into evangelists

Training in the form of short informal sessions (face-to-face or online) and ongoing on-demand support are the basics for encouraging adoption. Too much training or too formal a setting will put users off, and is usually unnecessary.

More important is that the information gathered in steps 1 and 2 are communicated to key users. They need to understand:

  • What their own needs are
  • How those needs are going to be met by the software
  • What the benefits are of using the software
  • How they can integrate that software into their daily routines

This requires face-to-face, personalised sessions which can’t happen unless steps 1 and 2 are successfully completed. The aim is to convert key users into evangelists who can then help spread usage through their own team, encouraging the people they work with to take the training and use the tool themselves.

4. Turn evangelists into trainers

Evangelists may find that it is in their own interests, having adopted the social software, to encourage their colleagues to also become competent with it. A minority of evangelists (and it only needs to be a minority), will also find it in their own interests to train their colleagues themselves.

These evangelists should be trained further and given the support and materials they need to become trainers themselves.

The advantages of having evangelist-trainers are immense:

  • They understand the day-to-day needs and working processes of their colleagues far better than an external trainer can
  • They can communicate with their colleagues more easily, in the same language
  • They have the opportunity to provide effective training on a far more informal, ad hoc basis
  • Given enough support themselves, they can then support their immediate colleagues

5. Support bottom-up adoption and emergent behaviours

Training and support should not be limited to named groups, and should be made available to all users. ‘Volunteers’, especially, should be encouraged. The most influential people in a wiki or blog community are not those with official status but those who engage most enthusiastically. For example, wikipedia has about 90,000 registered users who have edited at least 10 times since they joined, but the majority of work is done by about 5% (4500) of these users. (Stats approx. for Nov 05.)

If people start to use social software in an unexpected, innovative, or informal manner, this should also be encouraged. If a user begins by putting their team’s coffee rota on the wiki, for example, this will help them understand how the wiki works and what benefits it brings.

Management support

As well as supporting bottom-up adoption, it is beneficial for there to be top-down support, but that support has to be based on openness and transparency. Managers and team leaders must trust their staff to use the tools correctly, but they must also be forgiving if mistakes are made. There is always a learning curve associated with any new software, and some people find social software daunting because they are scared of what they perceive as a high risk of public humiliation.

Managers and team leaders should:

1. Lead by example

By using the tool themselves for team- and department-wide projects, managers can encourage their colleagues to also use social software. By being active, showing subordinates how the new tools can be used, and demonstrating the benefits, manages can play a valuable role in fostering adoption.

In the software industry, this is known as ‘eating your own dogfood’, and it is essential in order to build trust, interest and understanding.

2. Lead by mandate

If the manager makes clear that this new tool is to be used for a specific process or task, it can help foster adoption and encourage reluctant users to learn how to use the tools. For example, managers can mandate that all meetings be documented on a wiki, with agendas written through collaboration and minutes being published as soon as the meeting is over, or that monthly/weekly update reports be made on a blog or a wiki instead of in a Word document or by email.

Key to leading by mandate, however, is that the manager must also lead by example. If one of his team puts a document on the wiki, but the manager comments on it by email, that gives conflicting signals to the team. Managers must be clear about which tool they expect people to use, and must use that tool themselves.

3. Lead by reminding

Managers can also increase usage by reminding colleagues to use new technology instead of old, e.g. when a colleague emails with a document to be proof-read, the manager can reply with a request to put it on the wiki.

4. Ensure there is adequate support

Managers must accept that their staff may require support, and they must be willing to allow staff to take time out to do training. They must also ensure that they have access to ad hoc support, so that problem can be solved quickly – it is important that there is someone tasked with ‘hand holding’ through the initial adoption period.

5. Ensure personal and business benefits reflect each other

Management plays a key role identifying and communicating the business benefits of social software adoption. When users understand these benefits (e.g. reducing email volume, speeding up projects, improving productivity, encouraging innovation), and see that the business benefits are in line with the personal benefits, (everyone likes to get less email) they will have greater confidence that the software is worth their own investment.

Understanding time-scales

In large companies with thousands of users, it is impossible to give everyone face-to-face training, but even with online screencasts* and help documents, it takes a significant amount of time for adoption to take place. Having a clear adoption strategy, and ensuring that the correct key players are identified and ‘converted’, helps to speed up the process, but it remains a fact of human nature that it takes time for people to become comfortable with new technology, new ways of doing things and, most importantly, new cultures.

The cultural aspect of implementing social software in enterprise cannot be underestimated, and it is the hardest aspect to overcome. It requires time, patience and understanding, but given those three, it too is a temporary obstacle.

Remember what your goals really are

Adoption isn’t a goal in and of itself. Lots of people use email an awful lot, but that doesn’t mean that it’s being used well. Think about what your ultimate aims are; make them discrete, measurable and attainable. Go for ‘reducing occupational spam’, for example, rather than ‘improve communications’. Measure your email usage before you start, monitor it whilst you adopt, and report back regularly so that people can see the progress that they are collectively making.

Wikis are a very powerful tool within enterprise, but like any other IT project, it takes thought and planning to ensure successful adoption.

* Screencast: Digital recording of a computer screen output, often with audio instruction.

03.03.06
by

My network, my tools. Your network, MySpace.

Last Thursday, I spoke to my friend Steve Klein’s multimedia journalism class at George Mason University on one of my last days in Washington. I’ve spoken to his classes before, and I usually have highlighted some of my own multimedia projects.

Speaking at Steve Klein's class

But this time, I wanted to show them some of the stuff that was happening at the grassroots level with third party web tools instead of Flash or big monolithic content management systems that are good at serving up lots of pages but not so flexible. I was really inspired by a post by Argentinean journalism professor Julian Gallo who showed how easy it was to tell multimedia stories using these new tools.

I kinda assume that anyone younger than me eats, sleeps and breathes this stuff, so I was a little surprised that very few of them had heard of sites like Flickr, Odeo, OurMedia, CastPost etc. By using these sites and services, it’s possible to build very compelling multimedia stories.

They hadn’t heard of these sites, but they all knew about MySpace and Facebook. I didn’t think that the class was somehow behind the curve; instead it reinforced a couple of ideas.

1) Don’t be fundamentalist about my tools.
2) The internet isn’t just about information. It is social.
3) My tools for my community. Your tools for your community.

Blogs and Flickr really do help knit my London social network together. When I got back, friends said I must have had a nice break based on my pics in Flickr.

I never got into MySpace because it disturbs my sense of online feng shui. But these kids talked about how their friends were trying to get them onto Facebook or MySpace. And one student wanted to do her project on how other students were passionate about MySpace.

They were doing the same thing I am doing, but their community uses a different site or service.

I shouldn’t gloss over point two. I have a really hard time getting people to understand that using the internet is social, not anti-social.

It’s anti-geek prejudice that just doesn’t square with reality, but that’s another post for another late night.

02.19.06
by

Future of Web Apps, a week or so later

Since the Future of Web Apps, I’ve been a wee bit on the busy side, flying to Washington DC, enjoying the snow, and doing an absurd amount of shopping (mainly of the geek variety). In between all that, I’ve been thinking a lot about the presentations I saw.

I’ve done a lot of conferences over the last year, and had started to worry that I’d got a bit jaded and bored by the whole sitting about listening to people opine schtick, but the Future of Web Apps was just a great conference. Ryan and Gill Carson did a sterling job of getting a group of fascinating speakers together, along with 850 delegates and wifi that didn’t crap out.

Whilst there were a lot of really good talks, Joshua Schachter from Del.icio.us was definitely a stand-out for me. I’ve historically had my problems with Del.icio.us, but I was very impressed with Josh’s honesty and openness about the lessons he’s learnt, many of which I think are relevant not just to those developing web apps, but for anyone doing any sort of project that involves the public in any capacity.

Some gems:

Watch for interesting behaviour in the system. If people do things you didn’t expect or intend, that’s neat.

Don’t look for problems you don’t have, because someone else who is passionate about it will solve it better than you can.

Watch what you find your time doing. If you spend a lot of time building a feature that no one uses then that’s a waste.

If you’re doing something different, then understand where you’re breaking away from normal behaviour.

David Heinemeier Hansson was also really interesting, with a view on programming that differs quite significantly from that of many people I know. The way he puts it, Ruby on Rails is about minimising the number of times you have to reinvent your wheels.

Not reinventing the wheel is something that people should think much more about, not just in programming but in all aspects of life and business. We all have learning curves, but we need to make them as flat as possible and learning ways to cut down on repetition and reinvention. I liked quite a bit of the stuff that David said:

Look for patterns to abstract, conventions […]. Look for relationships between things. Conventions are there for the 80% of the time. When you work inside those conventions, you don’t need to do work, because you can get the conventions to do it.

Flexibility is overrated. The assumption is that flexibility is good, but you are trading valuable parts of your system away to get flexibility, and usually it’s not worth it. We should stop chasing flexibility.

It’s not about whether something is possible or impossible, it’s about whether it should be encouraged or discouraged.

Create invitations to do better, reminding you that you should be consistent, that you should be creating tests, and that you get benefits from doing things the right way.

I still have a lot of thinking to do about all that I heard, and it’s rare these days that I come away from a conference with my head full and my enthusiasm all a-bubble. I think it’s because this was a conference for developers, and I’m not a developer.

Blogging conferences, for example, rarely leave me feeling that I’ve heard something new or interesting, because most of what’s said is what was being said last year, or two years ago, or before even then. Conversations with bloggers, yes, that’ll do it. Blog posts too, even though I read so little these days. But rare is the blog conference that has be bouncing with newly-learnt gems.

Maybe this is about comfort zones. Sometimes your comfort zone gets so comfortable that it gets dull. Put yourself outside of that, into strange new territory, and suddenly it all looks exciting again.

All that said, though, as I sit here writing this, I’ve just discovered that BlogTalk Reloaded is scheduled for October 2 – 3 in Vienna. Will I be there? Absolutely. And I’ll be hoping that it leave me as excited about blogging and social software as BlogTalk 2.0 did in July 04.

02.19.06
by

Good Night, and Good Luck

Tuesday night, Suw and I saw Good Night, and Good Luck at the Uptown Theater in Washington, an old movie palace that opened in 1933. It is one of my favourite places to see a movie anywhere. A couple of years ago, I saw a restored 70-mm print of Lawrence of Arabia there on the huge curved screen. It reminded me of what movies were all about at one time: Grand spectacle.

But Good Night, and Good Luck was almost the opposite of that huge epic blockbuster, a film so understated, so anti-Hollywood that it seemed at times swallowed by that massive screen.

Murrow v McCarthy

The film followed the battle between Edward R. Murrow and the paranoid Communist hunter Senator Joe McCarthy. It started off with Murrow’s speech to the RTNDA in 1958 in which he said that TV was a powerful medium but risked becoming nothing more than a box of lights and wires and then flashed back five years.

There were actually two battles in the film. One between Murrow and McCarthy and the other between CBS head Bill Paley and Murrow. I was impressed with the development of Paley’s character in the film. He wasn’t portrayed as some mindless, corporate goon so focused on profit that he put Murrow in a straitjacket.

When Murrow reminded Paley that he had promised a firewall between corporate and editorial, Paley said that Murrow had to remember the other employees of CBS that he might jeopardise by going after McCarthy.

Maybe it’s just the info-junkie in me, but the film left me wanting to know more about the main characters, more about the history. Possibly that is what a good film or story or blog post does: Stimulate curiosity, leave unanswered questions. If you’ve seen the film, let me know what you think.

‘Crusading journalism’

I found the journalist in me feeling a mix of awe and discomfort at Murrow’s closing commentaries on See It Now. Murrow was an amazing writer and journalist. His writing and delivery were inspiring.

But as Murrow was reminded in the film: “We report the news. We don’t make the news.” It’s often been something that I have struggled with as a journalist. Sure, I have my own views and opinions, but I also believe strongly that my job is to report and let my readers, viewers or listeners to make up their own minds. I’m still uncomfortable with commentary, editorialising.

Murrow didn’t mince his words. He saw something that made him feel very uncomfortable in Joseph McCarthy and his anti-Communist witch hunts. And he tapped into the terror that many felt that their lives could be ruined if they were accused of being Communists.

After the broadcast, Murrow’s team grabbed the newspaper’s to see their reviews. The New York Times called it “crusading journalism at its finest”. It was fearless.

Dysfunctional relationship

Could journalists in the US do this now? I doubt it. It’s not just that the US is so divided. I sensed a trust that Murrow’s audience had in him to tell them the truth, even if it was the truth as Murrow saw it. Murrow challenged his audience doing pieces on not only McCarthy but also the shameful conditions that migrant workers suffered. He took on big tobacco, the situation in the Middle East, just to name a few.

Can the American media challenge its audience without being challenged itself? I don’t think so. Allowing oneself t be challenged takes a strong relationship, and right now we in the media don’t have that kind of relationship with our audiences.

Some people these days say that in this new world of journalism, our job is to stimulate and facilitate a debate. At the Beeb, we call it the global conservation. To play that role, I really want to be able to challenge and be challenged. But that is going to take developing a new relationship with my audience.

This is where blogs come in for me. To do this, I’m going to have to listen as well as talk. Blogs allow us in the media to do that. If only we would.

02.14.06
by

Don’t need a weatherman

Suw and I are in Washington DC mainly so that I can get my UK visa for the next year, and for me, it’s also a chance to see old friends. I was based in Washington for six and a half years from the Clinton impeachment through to George Bush’s second inauguration last year.

We landed last Thursday evening to warnings of impending doom. A snowstorm was on its way, more precisely a nor’easter. For those of you not steeped in American meteorological lore, a nor’easter is when a storm comes up the east coast of the US. In layman’s terms, the warmer, wetter air from down south slams into the cold air up the coast and voile, lots and lots of snow. DSCN0267.JPG

The last really big one happened in Washington on President’s Day weekend of 2003. It dumped a couple of feet of snow on Washington. My car was buried for a week behind a four-foot wall of snow left by the plows.

Weather weenies

Washington really can’t cope with snow, well, that’s putting it mildly. The town freaks out with even the mere rumour of a threat of inclement weather. I just don’t get it. It’s not like the city doesn’t have wintry weather.

And Washington really doesn’t know how good it’s got it. I grew up west of Chicago, and I have childhood memories of the Blizzard of ’79 when something like four or five feet of snow got dumped on us. My father, who is six feet even, had to go up on the roof in the middle of the storm to shovel off the chest-deep snow to keep it from collapsing.

Unfortunately, he dumped a good chunk of it right by the front door. I was about the only one small enough to squeeze into the front door until sometime in April.

Talking about the weather

Sorry for prattling on about weather. It probably has something to do with my storm chasing days as a cub reporter in western Kansas. Well, that in the fact that talking about the weather was one of the icebreakers I used when interviewing laconic Kansans who viewed me with deep suspicion. As they said, often: “You’re not from around here are ya?”

But weather is a real obsession for people. I almost enrolled my father in a 12-step programme for addiction to the Weather Channel. He had this habit of beginning every phone conversation by telling me the temperature of where I happened to be at that time, whether that was London or Washington. It was useful when planning what to wear for the day, but slightly freaky that my father knew my local forecast better than I did.

Here in Washington, local TV stations had their network of local weather watchers who sent in pictures of how deep the snow was in their back yards. I wonder why newspapers haven’t picked up on this or created spaces for their communities to talk about weather.

Sure, when I go into a weather site I want to know weather, quickly. But I wonder why news and weather sites don’t create more tools, more spaces to bank on this natural talking point.

Oh well, Suw and I survived the Blizzard of ’06. In Washington, it managed to coat the city in a beautiful blanket without really causing that much disruption. Plenty of Flickr pics to follow.

02.08.06
by

FoWA: Building a web app on a budget – Ryan Carson

What’s the big deal?

You don’t have to be big anymore. Everyone remembers Boo.com. They raised 130m and have nothing to show for it. Now, you don’t need to be anymore and that’s a huge change. It’s changing the entire landscape of the market with a team of 1 or 2.

So why now? Why hasn’t this happened before? Couple of basic reason: broadband is widespread; people are more comfy with web apps like Gmail; hardware is dirt cheap, don’t have to spend 5m on one Sun server like Boo.com did; open source software so there’s no need to go for an expensive .net platform.

What’s enterprise?

Mass market, 1000+ users. Meant to be apps used by 1000s of people. Not necessarily a lot of disk space or bandwidth but should be able to handle a lot of people.

What’s ‘on a budget’?

Under 30k. Minimum you can bring an enterprise web app to market today on. If Carson Systems can afford it, then you can too.

DropSend is used for sending and storing large files. Common problem – can’t email a 10meg file, can’t explain FTP. DropSend is the answer to that. Can store large files online.

It was a problem that Ryan had.

95,000 users in under two months. Five colo servers in San Francisco. Desktop apps for Mac and Windows. Have an API which will be released soon. PHP, AJAX, MySQL.

The most important thing

Make sure your idea is financially viable. use common sense, will people pay for it? Be cautious about your projections. A lot of guesswork. Acquisition my ass – aim for profit from the beginning. Acquisition is not a sure thing. If you don’t know it’s going to happen then you are betting a lot on that and it’s not smart. If it happens, then great. Forget about the whole ‘is this another bubble’ crap.

The budget

Once you’ve decided that your app is financially viable, set a budget. We had a hard time with this. How do we know how much this costs? We’ve never done it before.

So budget depends on project, but I’m going to explain about DropSend and be really honest about figures.

Branding and UI Design: £5,000

Slightly cheap, but did a deal with the designer and got a friend bonus, but our designer went to Bath, lived at our house and did it in a month. If you get UI wrong you’re screwed, but if you get it right then you’re sorted.

Development: £8,500

Good deal, pretty cheap. Offered a small percentage of equity in the product instead of a higher price.

Desktop apps: £2,750

Found someone who did Win and Mac, but next time will find specialists.

XHTML/CSS: £1,600

Really good deal. Guy was amazing, nice semantic code, not telling you who he is.

Hardware: £500

Hosting/Matinenance: £800 per month

Can afford outages. They’re not great, but difference in cost of having an app that’s up most of the time, or up 99.9% of the time is huge, so ‘most’ was fine. The hosting co helped architect the system, put it together, deploy it, and maintain it. Still cheap. That’s for five boxes. If you have one box, you don’t need the same services.

Legals: £2,630

Accounting: £500

VAT, invoices, integration with Quickbooks, etc.

Linux specialist: £500

To set up the dev box, virtual host etc.

Misc: £1,950.

Taking a trip, laptops crapping out etc.

Trademark: £250

If you spend time on your branding then you want to trademark your logo. Simple. Don’t need a lawyer unless you’re worried about a conflict. Do it early, before your finish your branding.

Merchant Account: £200

NatWest said taking recurrent payments was too risky. So had to go with Halifax-Bank of Scotland.

Payment processor: £500

Total: £25,680

Need to make sure that you have cashflow. So Carson Workshops funds DropSend, because it’s hard to work full time on a web app without bringing any income in.

So the reality of this is that it took us a year to save the cash. Carson Systems is 2.5 years old, and for the first year I worked my ass off to save up. If it does take you time, you can spend that time learning, picking up tips, maturing as a company.

How to build your team on a budget

You need good people but you can’t afford them. Couple of ideas – go for rock stars, go for quiet talent. People who are well known are expensive and busy. So find someone that you trust, someone who is not well known but good. They’ll be cheaper.

Offer a percentage of equity (2 – 5%), so if you get acquired you give them a %.

Ask people for recommendations. If you work with someone who’s crap, it’ll cost you money because you’ll have to redo all their work. You can outsource. We tried India, initially. All the dev for DropSend was supposed to be done in India, but it didn’t really work out for us. Some of it was down to my inexperience as a manager.

Scalability on a budget

Crux of the issue when it comes to doing enterprise web apps. You have to be able to support a large amount of users but to start with you have no hardware to do so.

Buy just enough hardware to launch. Basecamp launched with one server. We were originally thinking about getting IBM blades, but it was stupidly expensive. But wait to see if your app is successful before you throw money at it.

Build scalability into the architecture of your software. Hard to predict, but things like running out of diskspace. Can you just plug in a disk and it’s happy? need to not have to unplug for a week.

Plan, but don’t obsess. I obsessed for weeks, dreaming about hosting, it was terrible. Don’t do that, it sucks. Worry when your app succeeds.

How to keep it cheap

First one is don’t spend money unless you have to. Unless you’re sure you need something, do not spend money on it.

No stationery. We wasted £1000. Dumb.

No shiny new machines. I know you want that MacBook Pro. Don’t do it. You don’t need it. I survived for a year on a crappy beige PC with a CRT monitor that took up half the room.

No luxuries. When you have the cash, spend it, but in the meantime bite your lip and survive.

No frou-frou features. We had lots of ideas but the more ideas you have the longer it will take to developer, the more expensive it is. Launch with fewer features, but launch quickly. when you do launch your product is going to be easier to use. Less features is good, in general. Obviously it has to work, it has to do something.

Before you spend £25, ask yourself if you have to.

Make deals. Give a small % away. Barter, e.g. offer free advertising to your suppliers on your blog. Us IM [and VoIP] not phone calls. Do as much as you can yourself. All the wireframing I did myself in Flash. I did all the bookkeeping and copy writing.

Shop around. First quote for hosting was £12,000 a month.

Pessimism has its place

You will go 10% over budget

You will go 3 months over schedule

Solution? Plan on it, put it in to your cashflow.

Holy crap! Lawyers are expensive

Terms of Service £1000

Can’t copy someone else’s service agreement. Need a Terms of Service.

Contract for freelancers, £800

Can’t just run on trust

Privacy Policy, £15

Clickdocs, which are legal docs which are dirt cheap. Can also get a ToS for your website if you want to.

Barter with your lawyers – every lawyer needs website. They always give you a one hour consultation, so always take them up.

Cheap software is your friend.

Basecamp for project management, can get the free plan if you’re only doing one project.

Trac for bug tracker

Skype and AIM for meetings

Subversion for version control.

LAMP or whatever other OS platform you want to use.

Cheap hardware is your pal

£200 Linus box dev server run from the office.

How not to spend money on marketing

Use blogs, word of month, viral. But do it without annoying people. If your app is viral that helps.

Writing. Great way to raise profile. If you have good ideas you can write for magazines. If you write a web app for business, email, say, Business 2.0 and offer to write for them.

What about Venture Capital

If I’m ranting about enterprise web apps and a budget, why wouldn’t you just go with venture capital?

You might need it. I’m not gonna say that everyone should not have VC. If you need to scale or expand very quickly, if you can’t afford to wait that year, then VC is a good answer if you’re willing to give away a huge chunk of your money. But you need a really good reason these days. If you can launch for under £30k, why give away 25 – 30% of your company?

Essentials

– Don’t spend money unless you absolutely have to

– Bring down the cost of services for bartering

– Cut your features so you can build quickly and get it out the door

– Be realistic, if not pessimistic, about your cashflow

– Plan for scalability but don’t obsess

02.08.06
by

FoWA: Ten reasons why you need to build an API – Shaun Inman

API facilitates requesting, manipulating and exchanging data. Successful API obscures the storage format of the requested data as well as the details of the retrieval process. Don’t want your API to break if you break your storage.

Everyone has an API these days. Who is using APIs? Well, who isn’t?

Websites, widgets, desktops apps, bloggers.

– Increase brand awareness

Lay people don’t care about APIs. But you’re empowering people to do something with your data. People like to talk about things that empower them, so if someone is using your API in a way that’s new, they’ll talk about it, build more buzz.

– Allows people to use their own data

Feel more comfy if you can pull your own data out and take it with you wherever you want.

– Build goodwill with developers

– A perfect excuse for a community

Pulls people together around a common feature central to your app.

– Solving programming problems with an API in mind can improve code quality

Less work, less revisions.

– Simplify internal reuse of data

Present your data in different ways.

– Allows others to extend the functionality of your application

Means people can do things that you weren’t going to do, or didn’t think of.

– Allows alternate input mechanisms

E.g. Ecto or MarsEdit for blogs.

– Unanticipated applications of your data

Sort of like the Grey Album, an unanticipated use of the White Album and the Black Album. Chicago real-time crime maps.

– Turn your program into a platform

02.08.06
by

FoWA: Happy programming with Ruby on Rails – David Heinemeier Hansson

Silver bullet for developers – motivation. We should be focusing on productive and motivation in our development, in the work we do. Not enough to be just working in an interesting domain, or customers who appreciate what you do, but you also need to enjoy the mundane things of what you do.

I’m most motivated when I’m happy. Motivation comes from happiness. Not far down to say that if happiness, is the key ingredient for motivation we should optimise for happiness to optimise for productivity.

Used to be a programmer who didn’t like programming, liked the end result but not the process of programming. Didn’t find that exciting. But found there was one key factor that me me happy about doing the actual work and for me that’s beautiful code.

Beautiful code is one of those things that’s hard to explain, it’s about feeling good about a single statement, expressing what you want to say in a way that’s aesthetically pleasing, that’s understandable, that’s right.

Your app is not a unique snowflake. It is not special. Hard for people to deal with the fact that they are not special. Most parts of most apps are just like everyone else’s. Most people do the same most of the time.

So Ruby on Rails optimises for the 80% of the workloads. Can’t optimise for special, can abstract special. So that’s not the work that we focus on with RoR, because it’s too hard.

To get people on board with this they have to believe that 80% of what they do is the same as everyone else, and the last 20% is special, is the snowflake.

One technique for making beautiful code is the notion of convention over configuration. Configuration is the annoying part of making software. First you do the work, then you tell the system how you did the work, then you tell another part of the system how you did the work. Programmers don’t like repetition. So beautiful code does not repeat itself. It express what it needs to express just once.

[Gives example of code.]

Look for patterns to abstract, conventions say in mapping. Look for relationships between things. Conventions are there for the 80% of the time. When you work inside those conventions, you don’t need to do work, because you can get the conventions to do it.

Configure once, the move on.

Flexibility is overrated. Assumption is that flexibility is good. Trading valuable parts of your system away to get flexibility, and usually not worth it. Should stop chasing flexibility.

Constrains are liberating. If you think about what most people are doing most of the time, you’ll get systems which are consistent.

Devil shows you the easy way, where something gets done today but tomorrow is tomorrow. On the other hand, the angel tells you to test things.

Not about whether something is possible or impossible, it’s about whether it should be encourage or discouraged. At this point I realised that PHP is the devil, because PHP was constantly giving me temptation to do the ugly thing. The whole language just encouraged me to be a slob. Yes, I could fight that, and that works until the pressure’s on, and then you listen to the devil.

Ruby on Rails is the angels, we’re trying to embed the angel on RoR. We’re making it easier to do the right thing, the clean thing, the pure thing, than the hack. You have to go out of your way to do something ugly.

Create invitations to do better, reminding you that you should be consistent, that you should be creating tests, and that you get benefits from doing things the right way.

We do this by allowing common patterns but showing you there is a better way to deal with these common patterns.

Conventions

Invitations

Opportunities

Expectation

Want to set up a community of expectation that people are interested in doing the right things, the clean things.

[Another code example. Hard to take notes on code without the examples.]

Extracting common usage. Reduce mental effort. Sometimes the beautiful thing is to get out of the way. Sometimes, the beautiful thing is not to try to abstract, but to be a snowflake, do the unique thing.

What do you need to use RoR

– Feel the hurt. If you don’t feel the hurt, don’t hear the devil whispering in your ear, you’re not ready for RoR yet.

– Appreciate agile. That a functional spec is evil. Appreciate tests.

– You can skip the vendor. ‘I’m not here for you’. Open source because you want to help yourself. Rails is solution to problems faced by the contributors.

Does it scale? Yes.