Red Badger recently switched away from Exchange Server to Google Apps and, after 5ish months, I can honestly say I think it’s one of the best decisions we’ve taken and we are collectively more productive because of it.

It was with some interest and surprise then that I was reading the hacker news thread last week about how Google have “ruined” Gmail with the latest tweaks. I guess I’ll preface this and say that until Red Badger moved to Google Apps I wasn’t a regular user of Gmail and so have pretty much learnt my way around based on the app as it stands now. I know a few long-time Gmail users in the Red Badger office have moaned about the new compose window etc, but I guess what you never had, you never missed and it’s never bothered me. I like it.

One of the books I’m reading at the moment, The Art Of Unix Programming, spends a lot of it’s time presenting the design patterns and ‘rules’ commonly used across Unix and the lessons we can take from those patterns to put into practice in our own development endeavours.

Three of these rules state that your application should be discoverable, transparent and obey the rule of least surprise, with the caveat that stuff can be surprising, so long as the first two rules are maintained such that those surprises are easy to learn. These three rule applied together often result in, the author argues, software that appears to be intuitive.

When I first read that, I guess I thought of Gmail. I always try to learn keyboard shortcuts to make my life easier and in doing so within Gmail I’ve found it incredibly intuitive. As a result I feel [random unprovable stat]% more productive dealing with mail and IM in Gmail than I ever did before.

Learning keyboard shortcuts can be a bit daunting. Obviously everyone can read the keyboard shortcuts, but my theory here is to present them in the context of common tasks (aka recipes) hopefully making them easier to pick up.  I’ve also thrown in a few modes of operating which, I hope, will help you learn a good chunk of the Gmail keyboard shortcuts and help save the world*.

Make sure you’ve enabled all the keyboard shortcuts first. Also I’m only noting down the Mac keyboard keys because I’m lazy and you can lookup the Windows keys yourself.

Empty Inbox

This is where all of this is heading. Aim to only have stuff in your inbox that you have to action. Everything else can be archived. That way when you start your day, or ask yourself “what next”, you should be able to carry out a Mailbox Triage starting from the oldest mail in your inbox regardless of whether you’ve read it before or not. Keep repeating the Mailbox Triage recipe until you have an Empty Inbox, or as close to it as is physically possible.

If I have more than ~15 emails in my inbox I’m not being ruthless enough or need to break out some common tasks to a Short Term Label.

Mailbox Triage

Start from the oldest email in the inbox, so that emails get treated in a first come first served priority order.

Open the oldest email in your inbox. Read it. Decide what action to take.
Respond. r to reply, a to reply all of f to forward.
Compose the message and hit Cmd + Enter to send.
If you want to apply a label, hit l + type the name of the label + Enter.
If no further action is required on the thread, hit } to move previous (ie. newer/up the inbox) and archive the current message in one fell swoop.
If further action is required, and you want to leave the mail in your inbox, hit k to just move previous.
Repeat until you reach the top message in your inbox.

The j and k keys move you next (older/down your inbox) and previous (newer/up your inbox).
The { and } keys move next and previous and archive the active message.

These two sets of keys alone save an epic amount of time and are the key (excuse the pun) to effectively triaging your mailbox.

Avoid using shortcut keys like v (for move message to label) – whilst useful, this will move the message to a label and return you to the inbox. The theory with this recipe is to remain in the current message, triage it and then move straight onto the next one until you’ve been through every email in your inbox.

Short Term Labels

Think of labels as being short term sorting pens. Ultimately you want to shepherd everything into Archive (and you’ll use search to find it again, if you need to… which you probably don’t), but labels are handy to get groups of actions out of your inbox and allow you to process them together at a later date.

For example, we’re on a recruitment drive at the moment so any CV that comes my way get’s labeled under ‘Recruitment’ and moved out of my inbox. When I have enough to process in one go, and the time, I can process them all at the same time (by applying the Mail Triage recipe), ultimately removing the ‘Recruitment’ label (and thus Archiving it) once I’ve progressed them to a natural conclusion. Once you’re finished with a label, remove it.

There maybe a few exceptions to this rule, but even as I look at my 1 long term label now, for product keys, I question if I really need it and couldn’t just as easily search for the product name when I wanted to find the key again.

If you have tons of long term labels, you lose the value of labels because you have to remember which label you might have applied when trying to find a message. Learn to use search.

Search

One of the reasons you can just Archive stuff in Gmail is that the search is so powerful. Anytime you want to quickly get hold of that email, hit / which will focus you into the search bar and start typing.

Most of the time you can use a keyword and find what you need, but there are lots of facets to help you be more specific.

Want to find something you sent? from:me
Want to find something that was emailed to Bob? to:bob@mail.com
Want to find something with a PDF attachment? filename:pdf

Moving Between Folders/Labels

Moving between the main folders (or system labels as they really are) in Gmail is simple, there are a number of g + key shortcuts, such as g + i takes you to the inbox (think ‘goto’ ‘inbox’). g + t slightly less obviously takes you to ‘sent’ items, being as g + s is reserved for taking you to ‘started’ messages.

Moving to custom labels is achieved via search. You could of course hit / and then enter ‘label:[your label name]‘ which is pretty quick. But even quicker is to hit g + l (‘goto’ ‘label’) and Gmail will pre-populate the search box with ‘label:’ for you. Enter your label name and hit Enter.

Once in a label, you can apply the same Mailbox Triage recipe until everything has been Archived and the label can be removed.

One Off Reply

For this to work you need to enable the “Send & Archive” button, within settings.
Use the up and down keys to focus the specific thread you’re interested in. Note the blue highlight, indicating which thread has focus. Hit Enter to open it.
Hit r to reply, a to reply all or f to forward.
Compose your message.
Hit Tab to focus on the Send & Archive button + Enter to action it.

Responding to an Older Message in a Thread

You’ve opened a message thread from your mailbox, and you want to go back up the thread and perhaps respond to an older message.

Press p to move previous/up the thread (older), n to move next/down the thread (newer). Note the blue marker indicating the selected message.
Hit Enter to open a message.
Hit r to reply, a to reply all or f to forward on the selected message.
Compose your message.
Hit Cmd + Enter to send.
If no further action is needed on the thread, hit e to Archive it. Don’t forget it will return to your inbox if anyone replies.
If further action is required and you want to leave it in your inbox, hit g + i to return to your inbox.

Moving/Labelling Multiple Messages

This is especially handy when, let’s say, you send out a meeting invite to a whole bunch of people and get lots of responses clogging up your inbox.
Use the up and down keys to focus a message.
Hit x to select the focussed message.
Move to the next message, hit x again. Repeat until all relevant messages are selected.
Perform an action, such as e to Archive them all. Or l to apply a label to them all.

If the action you applied didn’t move the message from the current view, they will still be selected. Hit * (shift + 8) and n to ‘select none’

The Interesting, but not Important

How long has it being hovering in your inbox for? Do you really need to read it right now? Archive it and search for it later when you have time/realise you needed to read it.

Hitting e on any message, from anywhere in your mailbox will Archive it.

Don’t Delete Anything

Unless you’re actually anywhere near to running out of space, why delete anything? (Apart from maybe emails from recruitment consultants or notification emails).

Chatting Whilst Doing Other Stuff

To start a new chat q + search for the contacts name + Enter.

If you complete the chat Esc to close and return focus to your mailbox.
If you want to leave the chat window open and deal with your mailbox, Shift + Esc and your mailbox will have focus.
Pressing Esc again will re-focus you back to your last active chat window.
Alternatively you can hit Cmd + , to focus the last chat window. This has the added benefit of cycling through all your open chat and compose windows, when continually pressed, allowing you to move between conversations.

What did I just press? What just happened?

Something unexpected just happened? Press z to undo the last action.

What keyboard shortcut can I use to do this?

Can’t quite remember the keyboard shortcut? Feel like you can probably achieve something with the keyboard instead of reaching for the trackpad? Shift + ? will bring up the keyboard shortcuts cheatsheet. I love this. It reminds me of the days when I was learning all of Resharpers keyboard shortcuts and used to have the cheat sheet taped to the desk in front of me.

That’s it – now go practice. It will take time, but I promise it will save you time and improve your life. Relatively speaking.

@dwynne

*Now you’ve got more time to help save the world instead of dealing with email!

Estimating how long something is going to take is a part of everyday life, and as most of us know, we humans stink at it. Yet as software developers, estimating how long features and functionality will take to develop is all part of the job description.

I was explaining Red Badger’s project sizing technique the other day to a client who noted that we had a “very scientific” process. I think what they really meant was that it appeared very mathematical and exact (which it isn’t and beware anyone who tries to convince you that estimating can be), but taking the comment at face value, they had inadvertently hit upon something.

The Scientific Method

In the scientific world it is a generally accepted principle that one can only draw conclusions from the evidence that presents itself. In other words – I cannot say something is so, if I have no supporting evidence. More importantly however, it is accepted that a scientific theory is rarely presented as fact, but rather our best guess given the current evidence.

Estimating software is, or should be, much the same. A customer explains the solution they ultimately want from 50,000ft and we have to provide a theory for how long (and therefore how much) it will take to achieve. It should come as no great surprise then to realise that the fidelity of the theory produced is going to correlate to the fidelity of the evidence upon which it is based.

Let’s do an experiment. Look up from wherever you’re sat right now and look out your nearest window. Pick out 2 objects in the distance, one quite close to you and one further away. Next take a guess, in centimeters, as to how far away from you the first object is. Now do the same for the second object. We now have 3 data points; the distance to the first object, the distance to the second object and thus the distance between the first and second objects. How accurate do you think the estimates you just made are and how much money are you willing to bet on them being correct?

If you’re willing to bet more than a tenner on your guesses, then please do give me a call and I’ll happily take your money.

So how do you set a budget?

The Truth About Budgets

Here is an almost universal fact – most projects have a budget assigned to them before anyone’s really done much thinking about how much work is actually required. What does that mean to the people who will work on that project and what does it mean in relation to what the customer can expect at the end?

Whilst there are exceptions to every rule, more often than not projects are completed and the results put to use. If we put aside the quality of the result for a moment and instead think about the solution created, I would argue that its complexity will correlate directly to the original budget dictated for the project.

If you want a website building and set a budget of £500 – you can almost certainly get a website that will present the content you provided. You probably won’t be able to update the content yourself after the fact and maybe it doesn’t work or look quite right in some browsers – but you did it, you got yourself a website.

If on the other hand you set a budget of £500,000 – you will also get a website. It will be entirely content manageable, have great design, be SEO friendly and look good in every browser and on every mobile device.

So if estimation is unreliable and budgets are set ahead of time anyway – why bother estimating?

Project Sizing

If you wanted me to build you a table, I can already start chunking that requirement up into units of work to give us an idea of how much effort might be involved. We know we need to source the correct wood, create the table top, turn the legs, stain the wood, varnish it and get it delivered.

We don’t need to tie down every single specific at this point and nor should we. Picking the correct thickness of wood, number and placement of table legs are things we can discover and agree together along the way when we collectively have more data and have maybe got some wood samples to play with.

What is important however is that we agree, in general terms, the primary tasks that we need to complete so that that we’re going to have a table at the end of the project that you can use and with which you’ll be satisfied.

Once we’ve broadly agreed the chunks of work that need completing – we can start to estimate them using relative estimating. If we think back to our experiment earlier when we tried to estimate the distance of 2 objects visible out of the window in centimeters it probably felt pretty futile to be thinking at such a high fidelity. Rather than saying the first object was 10,734cm away and the second 19,764cm away – wouldn’t it be much easier to say the second object is further away than the first, probably by a factor of about two? This is relative estimating.

Using our experience, we can quickly estimate that turning the legs is about two or three times more complicated a task than creating the table top and that staining the wood is about half the effort of creating the table top and so on.

At the end of this exercise we have a list of the tasks involved in building the table and low fidelity feel for how large each task is relevant to the others. Next we take a few of those tasks, ideally the ones we understand best, and think about them in more detail down to how many days or hours we think that task might take. Finally we can use that data to extrapolate out a likely time for all our other tasks using the relative estimates we’ve already created.

We now have a low fidelity view of how long all the tasks might take to complete. It’s important to stress that this isn’t a guarantee but a guide. It is enough data for us to match the effort we think is required to the available budget and rule ourselves in or out at an early stage without having expended too much effort or set any false expectations.

We have a theory based on the data available to us.

In Scrum the units of work we described are our product backlog, each individual unit of work themselves are epic user stories and the relative estimates are story points.

Tracking Progress

In Scrum, when it comes to estimating sprint backlog tasks, you estimate in hours. This estimate is not a promise however, it is a guide used to provide feedback as to the status of the sprint. At the end of each day, the developer updates that estimate. They don’t simply subtract the number of hours they’ve spent working on the task, instead they use their the insight and knowledge afforded them, having been working with the task in such close proximity, to provide a new high fidelity estimate. Typically this estimate would be lower than the original given that they’ve spent time working on it, but it might not be. If they’ve started working on something we thought would be simple, but it turned out to be more than had been bargained for; they simply increase the estimate.

This is the iterative feedback loop at the heart of scrum and one of the tenants that makes it agile. Those daily, iterative estimates provide you the indicators that things are either on-track or not going as you had planned – they provide you the opportunity to be agile and to react to the situation early.

Practice Makes Perfect

The more you do something, the better your become at estimating how long it will take. Not least because you’ve done it before and so can build your experience into that estimate.

What time do you get up in the morning and why? For most people the time they get out of bed will be dictated by the time they need to arrive at their place of work or study. Most people, more or less, make it into work on time each day – which means they did a good job of estimating how long it was going to take to get showered, dressed, have breakfast and travel to work. That’s because they do it nearly everyday. Even with this practice in hand however, sometimes things go wrong. It snows, the train’s delayed, you hit road works or maybe you just got too drunk the night before and slept through your alarm.

As a project progresses it is natural to see a team find its rhythm and in turn for its estimation to become more accurate. Scrum takes advantage of this fact to give a more and more accurate view of the future the closer you get to crunch time, whilst factoring in unforeseen issues that can come out of the blue. In both cases it empowers you to take, early, corrective action.

Understanding the Tasks

There’s a great blog post from Dr Tom Crick, about the so-called Feynman Problem-Solving Algorithm which states:

1. Write down the problem.
2. Think very hard.
3. Write down the answer.

Often when we write down a problem we presume to know the answer, but when it comes down to the nitty gritty we discover we perhaps didn’t know as much as we thought. Estimating tasks as a team forces us to think things through and collectively agree on a broad approach to a problem before we start.

Estimating can be a painful process and it is never more painful than when you don’t have enough data to base your estimate on. It’s at this point, you should stop – step down the fidelity of the estimate, ask for more data and move on.

Once again we’re able to identify issues or unknowns early in the process, flag them and attempt to get them resolved before they become a blocker to the project delivery.

The Science of Estimating

People have a penchant for fixed price projects because they’ve had too many experiences where projects have run over budget so horribly. You could argue that they ran over because the estimations upon which the budget was based were poor. Or you could accept that estimating is such a fallible tool, that to place a bet the size of a project budget on initial estimates was foolish in the first place.

Software development isn’t about “ones and zeros” as often people like to say, it’s about human interaction with a system. And when humans are involved infinite variables are suddenly introduced that need to be continually accounted for.

The truth is that whilst estimating is a valuable tool, it has to be applied in the right manner at the right time. Crucially it should be treated as an iterative process that is continually revisited to increase it’s fidelity inline with the available data.

Estimating is a science. And science is iterative.

As anyone who has followed Red Badger’s progress over the last 3 years will no doubt know, we’ve changed a fair bit from when we started out. Undoubtedly a good thing – being adaptable is what we’re all about and the only way to survive.

At the end of last year I wrote about my recent experiences at having switched from using Windows on a daily basis since it’s very first incarnation to using Ubuntu instead. It was a rewarding experience; I was, and still am, really rather impressed with Ubuntu. But as I noted at the time there were downsides (most notably the battery life) and in the end I decided to get a Mac. (I got a 15” MacBook Pro with Retina display, 16GB RAM and a 512GB SSD since you asked).

I’m only really a month into ownership and not quite ready to fully asses life on a Mac as I’ve been mostly writing stuff since I got it and haven’t had much time for any hardcore dev work yet. That said, what I have experienced of it so far I am loving, but my true assessment will have to wait for a future blog.

When you join Red Badger, we let you choose what hardware you want. You can pretty much have whatever you want so long as it gives you the best opportunity to get your job done. When we started Red Badger we were predominantly Windows, with some UI Devs and Designers preferencing Mac. Over the last 3 years that’s shifted significantly to the point where come the beginning of the year, Windows is almost in the minority. I recently carried out a little impromptu survey as to what OS each team member was using, how long they’d used it, why and whether they had any intention of switching in the near future.

Here are the headline stats:

• Overall we’re currently 60% Mac, 20% Ubuntu and 20% Windows.
• Developers, taken on their own, are 66% Mac and 33% Ubuntu.
• 50% of our Mac users have had a Mac for 3 months or less, having switched from Windows.
• 100% of Ubuntu users have been using it for 6 months or less having switched from Windows.

Mac users gave some of the following reasons for their choice of OS:

• “Because it’s the best of both worlds, awesome dev using darwin and awesome GUI on top.”
• “The Mac is a much more pleasant experience than Windows”
• “Tech we’re now using works better on a *nix system and I really don’t want to move to Windows 8”
• “I’m not that fanatic of Apple products, it just happens to be Mac OSX that is my favourite…”
• “Familiarity, ease of use, well suited to web development, tied to preferred hardware design / form factor”

Windows users had the following to say:

• “The main reason is because this is the operating system that came with the laptop”
• “I have always used windows and find it easy to use.”
• “Have tried used Mac’s in the past but found them difficult but this is probably due to the fact that “I have been a windows user as far back as I can remember”

And the Ubuntu folk:

• “apt-get! Every tool easily accessible”
• “Fast and pretty reliable, has developed a LOT in a few years”
• “Same environment on deployed servers we work on which helps to do general CLI tasks”
• “Mainly due to the lightweight nature and the fact it lends itself perfectly for the technologies currently being used at Red Badger.”

80% the team said they had no intention to change their OS in the near future and the rest were fairly non committal about the prospect. There were a few rumblings about OSX becoming a bit to iOS like and various other annoyances with Apple but no real threats to switch.

As our recent Tech Round Table demonstrated, the last 12 months have shown a real flux in the tech we’ve found to best solve the problems at hand and it appears as our choice of OS has, perhaps unsurprisingly, largely followed suit. It really has been a fascinating and exciting few years; I personally love the speed at which we adapt, change and almost unceremoniously replace that which we feel can be improved.

In our case it appears as though Windows has been a casualty of that mentality of late. To my mind, that doesn’t mean Windows is dead to me – it could just as easily be my next OS if it can provide a reason to be so; but Windows 8 certainly isn’t it.

Last Tuesday we got together as a tech team (developers, testers, agile project managers) and held a Tech Round Table of 2012. The premise was simple – let’s make a list of all the tech we’d used in 2012 and then figure out what we liked best, what worked well and what we’d like to learn more of in 2013.

Each of us took a Post-it Notepad and a pen, and started a quick review of each project we’d worked on in 2012 – noting down the tech, tools, languages and platforms we’d encountered along the way. As we started to each stick up our list of tech, and roughly group them, it became apparent we were going to need a bigger space to complete the exercise than the wall I had initially chosen…

We cleared a table and started to re-group the notes into more clearly defined categories until we had everything in more or less the right place and could clearly see each note and patterns started to emerge.

As we ran through each tech, sharing experiences and use cases it became clear that, bar a few examples, most everybody had, in one form or another, some exposure to most of the tech on the table. A fair amount of new tech to the team in 2012 had been learnt, implemented, tested and deployed to production. For those of us in the world of tech, we often take the level of change we encounter for granted, but it’s actually quite eye opening to take a step back and consider how much knowledge we are able to gain and put to great use in a relatively short space of time.

Most Common

Where piles had appeared, we could start to see the most common tech in use across the team. When taken together it makes for a pretty awesome stack and one with which you could build a ton of truly cool other tech. In no particular order, the most in-use tech is:

• Node
• Express
• CoffeeScript
• Mocha
• Jade
• Jam
• Less
• Bootstrap
• jQuery
• Redis
• MongoDB
• elasticsearch
• Vagrant
• Chef & Puppet

Most Popular

Next up we gave ourselves 8 votes each (not quite sure why it was 8, but that was the number we settled on) and put a dot, star, or in the case of Jon & Stu, a smiley face on the tech we either liked the most and/or had the most interest in. Unsurprisingly, there was a fair amount of crossover with the most common tech in use, but the placing wasn’t what you might expect:

1st Place

• Vagrant w/Chef & Puppet
• Jam

2nd Place

• Node
• CoffeeScript
• Bootstrap
• Redis

3rd Place

• Sinon
• Jade
• Capistrano
• Cucumber + Relish
• JavaScript Code Coverage (Istanbul / Blanket)
• Lawnchair

The most popular tech is heavily littered with tools and frameworks that make development life easier; Vagrant and Jam taking the top spot speaks volumes about the way our team works. If you simply take the 4 bits of tech in 2nd place on their own, you could build a lot of fast and scalable applications in next to no time. 3rd place is occupied by more efficiencies in Jade creating cleaner, more maintainable HTML and Capistrano for taking the guesswork out of multi-environment deployment. It’s also nice to see a few bits of tech in there that we’re keen to do more of this year in Cucumber, JavaScript Code Coverage and Lawnchair.

New Trends

DevOps is both an emerging trend in the industry and something that exploded into Red Badger with huge rewards in 2012. Vagrant together with Chef and Puppet have transformed how we think about provisioning platforms, both in the development environment and the cloud. Expect to hear a lot more about that from us on the blog soon.

The real-time web has also had a big impact on a number of projects we ran in 2012 with heavy use of both WebSockets and Server-sent Events (SSE) to create dynamic and constantly updated applications. Redis together with WebSockets/SSE are a match made in heaven.

I’m not sure I can get away with calling the Cloud “new” any more  but it was interesting to see that over the course of the year we’d had experience using most of the major big hitters in AWS, Azure, Rackspace and Heroku. We’ve always been heavily reliant on the cloud and still have no physical infrastructure of our own to speak of. All 4 of the Infrastructure/Platform as a Service offerings mentioned bring something slightly different to the table that we’ve leveraged across our various projects, but AWS has probably had the most usage with Azure and Rackspace usage tailing off.

What’s Missing

In a word .Net. Whilst we’ve certainly delivered projects during 2012 using .Net and have a long history of doing so, but there’s no doubting that within our own little tech trend, the move has been away from MS tech towards that of open source. The reasons why are probably the subject of another blog post entirely, but given our mantra of “choosing the best technology for the job” – it would appear that open source has fulfilled that edict more often than not.

What Next

We’ve been so busy during 2012 that we haven’t done the best job of sharing the fruits of our labour with you, dear reader. Our new years resolution has been to remedy that and we’re kicking off the year with a cornucopia of blogs that cover our favourite tech of 2012 – so stay tuned!

In the meantime, you can peruse the the list of tech we used in 2012 in all it’s gory details (and in no particular order) below.

@dwynne

The Full List

Frameworks

• PhoneGap
• ASP.Net MVC 4
• OpenRasta
• Express
• Express-Resource
• RailwayJS > CompoundJS
• Jekyll / Statamic / Middleman

Template Engines

• Jade

Data Serialization

• YAML

Platforms

• Node
• ASP.Net

Languages

• C#
• Java
• Objective C
• PHP
• Python
• CoffeeScript
• JavaScript
• Ruby
• PHP 

Storage/Data

• CouchDB
• Redis
• Neo4j
• elasticsearch
• MongoDB
• Lawnchair
• Rabbit MQ (amqp)

Identity and Access Management

• SAML 2.0
• WS-Federation
• OAuth 1.0a & 2
• AD FS 2.0

Package Managers/Dependency Managers

• NPM
• Jam + require.js
• Browserify
• Ender

Server Application Stack

• Nginx
• Varnish
• Pound
• stunnel
• IIS

Frontend

• Bootstrap
• jQuery
• Responsive Web Design
• Media Queries
• SVG / Raphael / Pablo
• Less

Client-side Frameworks

• Knockout
• Angular
• Backbone.js (w/Backpusher)
• Meteor
• Sencha Touch

Utils/Libraries

• NLTK
• Cheerio (like JSDom)
• underscore
• async
• winston
• bcrypt
• moment.js
• JSON3
• Revalidator
• i18n
• request + superagent
• docco
• styledocco
• Cake
• Grunt
• Nodemon
• Forever

Realtime Web

• NowJS
• socket.io
• EventSource > Server-sent Events
• Pusher
• WebSockets
• SignalR

Misc

• CORS
• Google Map API

OS/Apps/Services

• Ubuntu
• OSX Darwin
• Google Docs
• Sharepoint
• Sublime Text 2
• WebStorm
• YouTrack
• TestRail
• Git / Github
• WordPress

DevOps

• Vagrant
• Chef
• Puppet
• Concrete
• Travis CI
• Capistrano

Testing

• Mocha
• nyancat
• PhantomJS
• Should
• Sinon
• Chai
• Selenium
• JavaScript Code Coverage (Istanbul / Blanket)
• Supertest
• Cucumber + Relish
• QUnit

Cloud Infrastructure

• Azure
• Rackspace
• AWS / EC2 / VPC
• Heroku

Today we’re announcing the imminent removal of Birdsong, our Windows Phone Twitter client, from the Windows Phone Marketplace.

We started developing Birdsong on pre-release Windows Phone hardware and when it was released, almost 2 years ago, it was one of the first fully featured Twitter clients to hit the marketplace. At it’s height it was the top ranked paid for Twitter client in 91% of territories, and the #1 paid for social app in 51% of all territories.

To any casual observer it is fair to say that our zeal for maintaining Birdsong’s market position has waned and we now feel it fairer to remove it from the marketplace than leave it there until the next change in the Twitter API renders it unusable.

Our decision is fuelled by two primary factors. Firstly Twitter has made it abundantly clear that they no longer wish to encourage the development of clients that emulate the core Twitter experience. Any developer who has built a client around the Twitter API will have always been aware that they were ultimately at the mercy of Twitter, but in recent months Twitter have had a distinct change of heart in regards to 3rd party developers that has been well documented and dissected elsewhere to the point there is no need to cover it further here.

Secondly Windows Phone Marketplace has not proven itself, for us at least, to be a financially viable proposition at this moment in time. The revenue generated from Birdsong sales vs. the internal cost of development and push service hosting simply doesn’t add up. We genuinely have high hopes for the Windows Phone platform and still very much hope that it manages to find it’s feet.

We’d like to extend our thanks to all the users of Birdsong over the last 2 years, especially the enthusiastic folk who helped us beta test each version. We apologies to those who are still actively using Birdsong and are inconvenienced by our decision, it was not an easy one to come to. Thankfully our friends over at Rowi are offering a great Twitter client (both free and premium) and we’d encourage any Birdsong users to take a look at their app.

Since Red Badger started we’ve used a hosted MS Exchange Server from Rackspace and of course Outlook. The service has always been excellent; the uptime, the support and the speed. Never once have we really had cause for complaint, so why move?

Well here at Red Badger we’ve always had a belief in being technology agnostic and always trying to use the best tool for the job, and that belief applies to everything we do, not just the software we create. What hardware/software people choose to use at Red Badger is for them to choose, and our install base has changed quite a bit over the last couple of years. As it stands Windows is now in the minority, with Ubuntu ahead of it and Mac being the most common, as such the need to have a more flexible mail client has become more pressing. Outlook be it on Windows or Mac, is an effective enough tool but on Ubuntu it’s obviously not an option.

MS took an odd decision many years ago, that practically no other software company in the world would be able to take. They decided that they would only really make Outlook Web Access (OWA) work in Internet Explorer. If you’re using any other browser you’re in for a very cut down, plain text, experience. The decision to do this speaks more to IE’s incompatibilities than anything else, and an admission from MS that to get a rich web app to work consistently in all browsers is a costly affair. It was a terrible decision and in a world where web apps are becoming the norm it has left them at a great disadvantage. I’m aware that with Office 365 this situation has been improved somewhat, but oddly in Chrome on Ubuntu you still get the “light” OWA client.

The crappy OWA experience really kick started our interest in moving away from hosted Exchange Server and to trial Google Apps for Business and boy are we glad that we did.  Let’s make a little comparison between the two services (specifically Hosted Exchange with Rackspace vs. Google Apps)

No licencing cost for Outlook
2GB vs 25GB per mailbox
£10 vs £3.33 per user per month
Google Groups for company-wide mailing lists and discussion
Google Chat for company-wide instant messaging vs Lync? (no thanks)
Outlook Web Access vs. Google Mail Web-client
Google Hangouts for group video conferencing vs Skype’s premium Group Video
Google+ for internal social sharing (ie. Yammer)

The list goes on… in fact the list is pretty much every major Google service, but just for you and your co-workers. When you actually put all of Google’s apps together in a company ecosystem it’s really quite surprising how effective they become in helping to bring your companies communications together. And of course, as it’s Google everything works like a charm in whatever browser you happen to be using – with Google the browser is a first class citizen which looks like a much better bet today doesn’t it?

As a man who has spent his entire life using and making a living from working with Microsoft Windows, be it desktop or server, dipping my toe in the water of another OS has always been something I’ve frankly tried to avoid. However there comes a time in a developers life when you have to realise that the grass may well be greener on the other side and if you want to play with some of the more interesting emerging technologies, then unfortunately Windows is not where it’s at right now.

Having developed under Windows for years and years, it has nearly always been the case that the interesting stuff comes to Windows later or not all. Ports are often many releases behind their original counterparts. Application servers/platforms “can be made to work on Windows” usually with a few caveats, reduced functionality and/or using unsupported versions. It can often feel like you’re putting in a ton of upfront effort to simply get on some degree of parity before you can actually start being productive. You’ve got to ask yourself, why am I putting myself through all this pain?

With the latest few projects we’ve been working on, our desired tech stacks have included Node.js, Varnish, nginx, neo4j, redis, mongoDB, Vagrant and Chef. Nearly all of these technologies play natively in the *nix world and you can have the latest and greatest up and running in minutes.

Ubuntu opens up that world without the need to purchase new hardware.

The Installation Experience

As my laptop is about 1.5 years old now, my install of Windows had hit that point where the only way to get it running properly again was to rebuild – I started out with a clean install of Windows 7 followed by a dual boot installation of Ubuntu. Why not Windows 8? Well… why put yourself through the pain of the clunky “modern UI” on a laptop?

Historically Windows has usually been pretty good at finding most of the device drivers out of the box – although on my ThinkPad T420 it failed miserably for reasons unknown and I was left manually downloading network device drivers from the Lenovo support site, not to mention doing the Windows update dance.

Ubuntu on the other hand got everything – even the hardware keys and 3G modem (both missed by Windows). The in-built mic actually performs better under Ubuntu than it does under Windows, pointing at dodgy Window device drivers as opposed to poor hardware. Genuinely impressive stuff.

The Desktop Experience

Whilst Ubuntu isn’t as polished as Windows or OSX it’s not bad, not bad at all. I’ve predominately been using the Gnome window manager which has multiple desktops and a number of very well thought out shortcut keys, most of which stem from common patterns you’re already used to, that really increase productivity. Gnome’s sales pitch is that it is “designed to stay out of your way, minimize distractions, and help you get things done” and it certainly does – apart from a thin status bar running along the top of your screen, the rest of the real estate is for the stuff you’re doing. If one were being unkind about Windows 8 – you could describe it as simply a new window manager for Windows rather than any sort of paradigm shift in the underlying OS.

The biggest plus point has to be one of the best package managers and terminals in the business in which you find yourself spending an increasing amount of time. Once you’ve picked up a few basics and get used the common patterns, the speed at which you can pick-up and configure something new increases at an alarming rate – it’s a very rewarding experience. Oh and of course you get SSH for free, which makes managing your cloud servers a snap – no more remote desktop or PuTTy.

Where Ubuntu falls down is the lack of mature/polished desktop apps and in terms of pure “business” productivity, life is quite a bit harder.

We recently decided to migrate away from MS Exchange to Google Apps for Business (more on that another time) but before we did, the lack of a decent desktop mail client that would play with Exchange Server was a major pain and given that Outlook Web Access is a travesty, that represented a major drop in productivity. Compared to Outlook the alternatives available on Ubuntu (Thunderbird, Evolution) are pretty lacking.

Whilst there some genuinely great open source efforts such as LibreOffice, GIMP and InkScape; there just isn’t the same mass market competition that really pushes the quality bar that you’re going to find in the Windows/Mac world and you will find yourself making compromises.

Thankfully the ongoing maturity of web apps often provides a truly cross platform solution to the lack of some desktop apps. Some of the Chrome Web Store apps are excellent. TweetDeck for Chrome has proven itself to be a solid replacement for MetroTwit. The lack of a Amazon Kindle app matters not a jot, with the Kindle Cloud Reader which is excellent and allows for offline reading in Chrome. Google Mail and Calendar both support offline usage in Chrome too, including search.

System suspend/resume is a lot quicker and more reliable than Windows and given that Ubuntu isn’t infected with the Windows slow-down effect, the need to physically power-down becomes quite a rare thing.

It’s not perfect and does have glitches and occasionally crashes and getting some bits of desktop software or pluggable hardware to work/install can require a little black magic that is generally going to rule the non-techy out from using Ubuntu seriously on a day-to-day basis. When you’re not connected to power, the battery life isn’t as great under Windows, an area that hardware manufacturers and MS probably spent a lot of time tweaking and balancing to improve.

I’ve only really found myself needing to reboot into Windows when Word or Excel come calling. You can get a reasonable distance using LibreOffice to review documents, but when it comes to editing in those formats then you really need the real thing.

From a development point of view however, life is pretty sweet and there is much to enjoy. With Chrome, the Terminal and Sublime Text 2 in your pocket there’s not a lot that can’t be accomplished in a quick and light manner. I easily spend 90% of my time in those 3 apps, thanks in no small part to the gradual maturity of web based apps reducing the need for the desktop software.

@dwynne

A few months back I attended a talk at @fluxXstudios by Ted on the Informal Economy.  Wikipedia defines the informal economy as “a broad term that refers to that part of an economy that is not taxed, monitored by any form of government, or included in any gross national product (GNP)”.  Many of the examples Ted gave were of developing economies where practical people see practical opportunities to improve something and, as a by-product, make money.  The appealing nature of these examples is how simple and direct the solutions often are.  In townships where roads are nothing but mud tracks and moving stuff around in hard, innovation means creating a wheelbarrow with a larger tire that makes it easier to move in muddy conditions.

The informal economy is far from the preserve of the developing world however and can easy be observed on sites such as eBay and Etsy.  A group of people making their livings by dealing directly with their customers, generally without the assistance or interference of government regulation (or tax) and who live or die on the demand for, and the quality of, their product.  As with the innovation in the developing world, the rules of the game are ultimately the same – find demand that is being unfulfilled and fill it, the difference however is that the demand in the developed world is often born out of inefficiencies in large corporates.

My ThinkPad has a swappable expansion bay into which you throw an extra hard-drive.  I’ve ordered 2 different “official” drive bays direct from Lenovo over the last year, waiting weeks for delivery each time.  The first didn’t fit properly, the second doesn’t securely hold the drive without additional fittings that you can’t order.  Hop onto eBay however and you’ll find a whole industry of people manufacturing their own bespoke drive bays that cost a 5th of the price, ship quickly and fit perfectly.  Mine arrived from China this morning and has already replaced it’s inefficient counterpart.

There are rather satisfying parallels in the informal economy with the start-up philosophy.  Build something, give it to people, assess demand, get feedback, improve, repeat.  Out here in the real world, real economics applies – if you’re producing a crap product, no-one will buy it, you’ll get bad reviews and eventually you have to adapt or die.  The quicker you can adapt, the quicker you satisfy the latest demand and more successful you are.

In the developed, regulated/corporate, world we’ve been extremely effective at building in so much process to our decision making that innovation and passion are often trampled out of existence by the time an idea might get to the point of being implemented.  The biggest limiting factor to success is not starting something.  I think this is something I’ve learnt over the years – if you’ve got an idea that you think fulfils a demand, then prove it.  If it turns out you were wrong, no worries you’ll have other ideas.  If however you were right then you can figure out how to make the idea better, more efficient more profitable after you’ve first proved the demand exists.  And fulfilled demand = win.

It’s that time of the year again, when all the big players and related hardware manufacturers try to out do each other with product launches and roadmap announcements.  Amazon has announced a new range of tablets/Kindles, Nokia a couple of new Windows Phone 8 handsets, Microsoft has finished Windows 8, announced its own tablet hardware and has Windows Phone 8 announcements yet to come.  Apple meanwhile are expected to make some iPhone/iPad announcements this week that will likely create the biggest buzz of all.

Back in March 2010 I was at Mix in Las Vegas to take my first look at Windows Phone 7 I wrote a couple of blogs on my first impressions of what I’d seen and what it meant in the wake of the iPhone 4 announcement.  I summed up my feelings at the time by saying; if they manage to get “it’s a really good device, but not quite an iPhone” status – that would be a good result.  Two years on I think we have to say “it’s a decent device, but it’s certainly not an iPhone” and that that isn’t really good enough, as results have shown.

Microsoft made some good decisions; they went their own way with the UX (we won’t call it Metro anymore) for which they’ve earned well deserved plaudits. They provided a good developer experience – whilst a lot of Microsoft framework decisions are far from prefect, the emulator is excellent and if were a developer coming from a SL/WPF background you can be up and running really quickly.

Unfortunately they also made some bad decisions; the hardware is not up to scratch – outside of the core OS apps, performance isn’t good enough.  Add into the mix some of low-end hardware that ships with WP7 on it and a users experience and impression can vary wildly.  Over the last 2 years, I’ve used a WP7 everyday switching between 3 different handsets (HTC HD7, Samsung Omnia and a LG Something).  I didn’t really enjoy the HD7 (and it broke), I really liked the Omnia (but it broke) and I genuinely hated the LG (which I purposefully broke… I didn’t).  On one end of the scale the experience was positively awful and on the other, whilst is was good, it still wasn’t as good as it should’ve been.

After my Omnia broke and I gave up on the LG, I decided to switch back to my iPhone 3GS – a device which is now 3 years old.  I suddenly realised that over the last 2 years, I had worked out all the websites that provided the best mobile experience of their services (Facebook, Guardian, BBC and IMDB all do a good job!) because either the app for that service didn’t exist on WP7 or was a 3rd world experience behind it’s Android and iOS counterpart.  Unfortunately the WP7 eco-system is literally years behind that of iOS which largely set the template for smart devices and the “app” market.

Some decisions also got made on Microsoft’s behalf – their choice of technology in Silverlight could be seen as a misstep.  Prior the WP7 announcement I predicated that they would go Silverlight, it made so much sense at the time.  I was a fan of Silverlight, because I was a developer and it was a great development experience.  Silverlight never really got a foothold and then HTML 5 came along, and with a little help from Microsoft itself, really put the nail in the coffin.  Now that Microsoft really are pinning their HTML5 colours to the mast with Windows 8 and whilst it’s not really being fully announced yet, if Windows Phone 8 doesn’t follow the Windows 8 development model, I think we’d all be a little surprised at this point.

Even if switching the development mode is the “right” decision, it’s not likely to be a popular decision with WP7 developers, few of whom have really seen a return on their investment in the platform to-date in any case, so might not be willing to invest again when everything changes yet again.  There’s also a growing sense that WP7 was really a sticking plaster and WP8 will start again… again, which could mean Windows Phone 8 is less WP7 3.0 and more W8 1.0.  And with a 1.0 release comes inevitable bugs and wrinkles.

At the end of the day the only way to win in the consumer market is to provide users with a great experience – that’s all that matters.  Experience is everything.  Gimmicks, add-ons and short lived promises mean nothing in the end.  Most people who live outside the tech bubble that I, and most people reading this inhabit, are more concerned about whether the music they’ve already bought will work on it, will they loose all their contacts and can they play angry birds or watch the BBC iPlayer on it?  Almost more importantly, if the answer to any of the previous questions is yes – then they will expect a smooth and slick experience.  Users don’t know when they’ve had a great experience, but they certainly know when they’ve had a bad one.  So if the hardware is slow and apps stutter, aren’t responsive, miss features, are always behind other platforms or just plain don’t exist – users will turn elsewhere.

As I was 2 years ago, I remain hopeful that the platform can find it’s audience.  Microsoft have struggled a little in their new role as follower and really need bring some clarity to proceedings if they’re to make up ground on the leaders.

We were very pleased to be invited back by the BBC to attend the second BBC Connected Studio.  Cain and Alex had attended the first Connected Studio which had focused on Homepage, Search & Navigation.  Thanks to their efforts we progressed onto the subsequent Build Studio where our team brought their concepts to life and we’ve just announced that we’ve progressed again to the pilot stage.

This time around Sari & I took the short walk from the Red Badger workshop to the new Google Campus in the “the heart of East London’s Tech City”.  It’s so new the new car smell (read: “paint”) hasn’t had time to dissipate.  The focus this time around was Weather and Travel.

Rather than re-tread Cain and Sari’s already expertly trodden diary style accounts, I thought I’d try and take another angle on the day and provide an alternate view.  Given our experience so far, is the BBC Connected Studio programme a good idea?

Are real ideas created in a day?

I have approximately 43.4 ideas a day, most of them don’t make it past my internal monologue to my mouth.  The majority of the rest get shot down when it’s pointed out someone has already done it or actually implementing the idea would be too dangerous and/or against the law.

Coming up with an idea is easy.  Proving that it’s a good one is the hard part.  More to the point, developing the right skills to prove or disprove an idea is something that takes practice and this format is the perfect training ground.

Many people have spent many millions following through with their idea before proving it.  The lean start-up movement is about testing your ideas with your customer cheaply and quickly.  Looking your idea straight in the face and truly asking, is this a good idea or not?  And if it’s not, move on.  The PoC/Concept Lab/Launch 48/lean start-up (whatever you want to call it) is all about failing fast, failing cheaply.  Short cycles of trial and feedback, rather than the traditional secret bunker and big bang approach that’s littered with casualties and lost investment.

Who owns the IP?

The BBC have been pretty open from the start that the initial creative studio is very much an open pitch process.  If  you progress onto the build and pilot stages, these are covered by a mutual confidentially agreement – but you’re still ultimately working on your idea openly alongside you competitors.

In the first creative studio, there was the option to pre-book a closed pitch session for those who were pitching ideas that contained IP they didn’t want to share.  Interestingly at the second creative studio they had decided that all pitches should be open.

On the downside you have to show them yours and risk embarrassment.  On the upside they have to show you theirs and you get to checkout the competition in an open and healthy manner.  It’s fascinating to see what other ideas people are coming up with, and to see the common themes emerge.

We’ve always been pro open and honest, so the Connected Studio process fits the Red Badger ethos rather nicely.

Aren’t you being taken for a ride?

So two of you spend a day working for free, then a team of you spend 2 days working at cost, then another team works for 6-8 weeks after that.  All with the prospect that Auntie could say no thanks at any point.  Aren’t you being taken for a ride?

Anyone who’s been involved in a tendering/pitch/sales process of any kind will know; stuff takes a long time.™  They will also know that in the consulting game you’re basically selling your ability to do stuff better than anyone else.  If at any point your prospective customer doesn’t believe you can do it, doesn’t like you or finds someone else who can do it better and/or cheaper – you lose.

As I’ve said before when discussing concept labs, the idea is not to do things differently, but to distil best practice and fail fast.  In that respect the Connected Studio programme applies the same attitude to the pitch process.  If anything, the prospect that you get instant feedback is fantastic. If our idea really isn’t up to scratch, then put us out of our misery so we can move on to fight another day.  No problem.

Tell me something else

It’s a fresh approach from a huge organisation.  It’s a chance to tell the BBC what you think they should be doing, rather than doing what they ask you to do.

I’ve been involved in a lot of Proof-of-Concept-type projects and whilst they’re nearly always fun and enlightening, the toughest part is to do something positive with the discoveries you make.  The BBC have been quite wise in making a commitment up front to an end goal.

Ultimately the proof will be in the pudding as to whether they follow through on that commitment and whether the results from the programme go on to improve people’s lives.  But if you don’t try, you’ll never know.

@dwynne