Angry Monkeys

It's been a long time since we've posted an update, and for that we're sorry. We're not dead, we've just been busy elsewhere. Matt and I (Alan) have been working full time on a bug tracking app for web designers and digital agencies called BugHerd. BugHerd is a visual bug tracker for websites, like sticky notes for HTML. Things have been going awesome at BugHerd, and whilst we always had the intention of coming back to UsabilityHub and Five Second Test, it was becoming more and more clear that we were just never going to be able to.

So a while back we made a decision to get some help.

We'd like to introduce you to Nick and Tristan (You may have already used their app - the time tracking and invoicing app, Paydirt). They've been working hard rebuilding UsabilityHub from the ground up. They've made a lot of improvements already, but there are a lot more changes and features coming soon. We'll be launching the new version into beta in the coming weeks. If you're interested in trying it out shoot an email to [email protected] and we'll get you set up as soon as it's ready to go. As a treat, here's a look at the new dashboard currently in development (full design not implemented yet...this is just a sneak peek):

Once the new app is ready to roll, we will be shutting down the old app. This means two things:

1. Where possible your tests will be migrated to the new system. If for some reason we're unable to migrate all of your tests, we'll give you plenty of opportunity to get the data you need before we move to the new version. We don't expect there to be any problems, but because it's an entirely new system some tests may not make the journey.

2. As everything is new (including the database), you'll be asked to reset your password. It will be a simple matter of using the "reset password" functionality to choose a new password. If you can't remember what email address you used to sign up, just shoot us an email to [email protected] and we'll help you out.

I hope you're as excited about this huge new release as we are. Once again, I'd like to apologise for the silence of the past little while... it's not that we don't love you, it's just we bit off more than we could chew :)

Thanks for all your support and enthusiasm over the past few years, and here's looking forward to the next few!

Cheers,

Alan and Matt - UsabilityHub co-founders

This is a repost of an article I wrote in May of 2010. It was originally taken down at the request of our bank in order to be approved for an account.  Ironically, the reason we relented was because there was no other bank in Australia that provided the USD merchant account we need. The fact it was demanded that we take down the post only serves to highlight the point the post was making in the first place. This still makes me laugh.

Having had another 12 months experience in running startups, with two incubators and three trips to the US under my belt, a follow up post may be in order. In the meantime, by request, here is the original post.

------

You've all heard about how if you want to run a successful startup, you've gotta be in the US. Well, we're quickly finding out how true that is. But first a disclaimer...I'm not a banking expert. I'm new to the whole Internet Merchant realm, and this is a tale of my experience trying to get our business selling online. I know there are far easier options than using a customised solution, but looking to the future, this is something we wanted to achieve, and we're simply astounded at how something so seemingly trivial could be so damned difficult. If at the end of this you have a solution to our problems, by all means drop us an email at [email protected]. I'd love to hear from you!

It's not that our business is any different than a US based business. Our websites and applications would all be exactly the same if we were in Silicon Valley. We'd likely go about our business activities the same as we do here, we'd probably have the same amount of traffic, and make the same number of sales. The one big difference, is that by being in the US, we'd be in the US already! Sounds obvious, but that's where the Internet "happens". The majority of our customers are in the US, our hosting is in the US, our suppliers are in the US, our sales are made in US dollars and most importantly when you talk Internet, people don't look at you like you're trying to launch a mission to Mars.  Remove yourself from that ecosystem, and all of a sudden you find yourself asking questions which people don't understand, and trying to find information that no one has. Worst of all, you find yourself with a big fat lack of choice.

For the past 6 months one of our little applications, Fivesecondtest.com, has been trudging along earning us a nice bit of cash on the side of our usual consultancy work. It's not our main revenue source by any stretch, but that is something we're in the process of changing. As many readers will know, all our payments are currently handled by PayPal. PayPal, for all its faults, provides a cheap, flexible and easy to setup payment system. Whilst it is certainly doing its job admirably, as we move to the next phase of our little hobby, PayPal is no longer fitting the bill..... and this is when our problems started.

Our next product, Navflow.com. is designed to run as part of a subscription. When hunting around the web for ways to achieve this goal, we found a plethora of providers, gateways, carts and apps to meet our needs. So much choice!! Where to start!? Well for us, we'd be reading a heap about a little app called Chargify, and decided to check it out. I'm all for supporting those that are trying to do something different. Even if it is in Beta, we were keen to get on-board. 15 minutes after signing up, we had Chargify set up and plugged into our app. With a little tinkering, we quickly had a full test bed running that allowed us to subscribe, unsubscribe and switch plans. This is how the web is supposed to work! Fantastic!

So now the pain of learning happens.

Chargify is still in Beta, and whilst it is a remarkably polished app, it's not "feature complete" yet. For the most part this doesn't affect us, but the one thing that did catch us by surprise was their support for payment gateways. First of all, we thought Chargify WERE a payment gateway. This is an example of how we were more than a little naive about the world of credit cards and internet payments. We'd been spoiled by the one-stop-shop that is PayPal.

As it turns out, Chargify (as of writing) only support one gateway that supports Australian businesses, PaymentExpress. Well that certainly made our choice easier! So we went to Payment Express and found that to use their services we needed a Merchant Account. Ok, no problem, we had a business account already, it surely couldn't be too hard to get a Merchant account setup alongside that? Could it? We spoke to our bank only to find that they can set us up a Merchant account, but that we could only sell in AUD. Not only that, but prices have to be QUOTED in AUD. This is hardly appropriate given that around 1% of our customers are actually Australian. After much research and gnashing of teeth, it turns out that <REDACTED> are the only Australian bank (supported by Payment Express at least) that support multiple currencies....and that comes with a hefty up front fee as well as additional fees for every currency you want to support. OUCH!

So if we want to use Chargify, we MUST use Payment Express and we MUST use <REDACTED>. A quick look at transaction fees for all of the above quickly showed how big of a slice of our monthly subscription fees we'd lose. We'd make it all back again, but it's still a big punch in the face when compared to the relatively cheap PayPal solution.

This is where being Australian sucks.

If we were in the US, we'd have a choice of half a dozen payment gateways with Chargify alone, and we'd have a near endless supply of banks and merchant account suppliers queuing up to take their slice of our takings. But in the Internet backwater that is Australia, we have the choice of ONE bank that will do what we need to do, and they seem intent on taking a hefty slice of every dollar they can (they are a bank after all).

So the logical progression of thought here is that if we ditch Chargify, we can ditch PaymentExpress which means we can ditch <REDACTED>. Of course, we still want to sell in USD, so that means getting an international acquirer. We spoke to several other companies such as WorldPay, GlobalCollect, Chase PaymentTech and several others. Whilst the aforementioned providers could at least provide us Aussies with merchant accounts, the vast majority of "online" providers weren't set up to support Australian businesses. GlobalCollect and Chase, whilst helpful were quietly sniggering at our annual turnover, and politely showed us the door. WorldPay, our last remaining option told us that it would take up to TWO MONTHS to set up an account with them. WOW. In 2010, it takes that long to set up a payment gateway and merchant account?

So, we're back to square one. As an Aussie startup we have the choice of precisely one provider of Internet Merchant accounts, and they're EXPENSIVE. There are some fantastic cart providers (like Chargify) out there doing some amazing things. For the most part, they're not only simple to use, but also have excellent support and are crazy cheap to implement! The frustrating thing about all this is that the closer you get to a bank in the whole process, the slower the responses become, the worse the implementations get and all the while they charge you more and more for the privilege. 

Even when we thought there was a glimmer of hope, with Chargify announcing support for PayPal Pro, our hopes were quickly dashed. If you're in the US, PayPal Pro is an all-in-one account that let's you do everything you could possibly want, and for a very reasonable fee ($30/month). Connect that to Chargify, and you have an awesome subscription system that is not only flexible but is very cheap to set up and run. Of course, that's if you're in the US. In Australia, we're stuck with PayPal Payflow Pro, which is not only significantly more expensive ($150/month), but still requires an bloody Internet Merchant account from your bank!! Back to square one....again!

So it seems that whether because of banking regulation, or lack of competition, we're stuck with a cumbersome, expensive, inflexible, slow-to-setup payment system for one reason and one reason alone.... We want to do business globally, but we're based in Australia.

At least we have better beaches I guess.

I'm a bit of hacker. I've worked with serious software engineers, and I'm definitely not one of those, although I can be when it's required. They're the types that spend more time writing and talking about what they're going to code than they do actually coding it. The word engineer suits these types perfectly. A piece of software to them is constructed from piece by piece of pre-defined, pre-designed and pre-fabricated code. There is more art than science to what I do. I liken what I do to gardening more than building a bridge. To me, software is more of an organic thing and I start software the way I start in the garden. I pick up a shovel and start digging. Over time as plants grow (or die), the yard changes and you change with it. I'm not building bank software or landing planes. I'm building to an ever changing target, evolving my software to suit a need that is never well defined, never fully known. It's whatever I feel like making it.

The big disclaimer here is that sometimes I need to be an engineer. If I'm working for a client on a fixed price project, then obviously everything needs to be engineered to a certain goal. So I can work that way, I just prefer not to. My client work is structured and defined, my pet projects are the result of an ever evolving process of discovery and learning. Of course, that isn't to say you can forget about security, performance or reliability...but it means these things are just one part of an iterative process, not a project in themselves.

For the most part, not being constrained by things like "best practices" is a wonderful freedom. I think of something, and I start coding it. When I'm done, I might go back and tweak or even throw away the prototype and start again (kind of like how we're onto our second Japanese Maple, after the first one died). It's wonderful when you know nobody will ever look at your code, or discover your hacks, it allows you to solve problems now without worrying too much about later. It's like an author taking short cuts with facts, names and places instead of wasting time researching. It just gets in the way of writing the story. But there is a big problem with this type of development. What you gain in agility, you lose in portability. By coding for yourself, you're forgetting about everyone else. 

If you build a successful product, there is a fair chance that at some point you're going to need to get someone else involved. It may be as an employee joining your coding team, or showing a potential investor what you've been working on or it may be by releasing an API for others to integrate with your system. For the first time you're suddenly faced with that embarrassing feeling of your parents dropping in to visit...and it's the morning after a really really big party. It's at this point you suddenly regret all the shortcuts, the laziness, the hacks and the sambuca...oh Lord the sambuca!

That's where writing a public API from day 1 comes in.

You don't have to have your whole house neat, just the bits your parents are going to be seeing. Writing a public API as you develop your system forces you to keep a certain level of decency without constraining your ability to be agile elsewhere. By using your own API you also force yourself to follow the same rules that you expect others to follow when interfacing with your code. It prevents you taking shortcuts that you rightly wouldn't let anyone else take.

If you're an agile or "lean" developer, the one thing you never think about is what this app is going to need to do in the future. You're only ever worried about what it needs to do today. This means your code can evolve into a horrible flying spaghetti monster (if you believe in such things). What makes sense today, may not seem like such a good idea tomorrow. By having a well defined core API you have at least one part of your system (hopefully the important bit) that is well documented, well considered and well written. It's something akin to maintaining a tidy formal lounge whilst the rest of your house is being subjected to an ill-considered conga line.

When it eventually comes time to make your API public, it's already tested and known to work. You know what problems your users are likely to encounter, because you've already encountered them yourself. Best of all, you're not trying to shoehorn a heap of public points of access where they were never intended. Writing an API as you go means you solve a lot of problems before they ever happen...and all without having to think about it too much. The API is as flexible as you want it to be until the day you make it public.

As you grow your application, your API grows with it. The more reliable it becomes, the more likely you will turn to it rather than hacking in a new piece of code elsewhere. When new developers come on board they have something they can immediately recognise and understand. We're all terrible at documenting our code, but with a published API you all of a sudden are advertising what you're application does...you want it to be well documented. Your users won't stand for anything less. 

All of this is the main reason most developers recommend working on open source projects. Open source means everything you do is available for anyone to see. Hacks and cheats are found and highlighted by others, and hopefully you'll learn a better way in the process. You lose this benefit of peer review when you're working on your own private projects. Writing to your own API is the next best thing. Hacks look a whole lot worse when you have to document them for someone else.

UPDATE: This update has been postponed until tomorrow due to a minor, but time consuming to fix, issue.

We're releasing a small update today. Most of the changes are behind the scenes in preparation of some future developments. There are, however, some other changes as a result of these future changes. There are two main things to be aware of:

1. Test creation process. We've now made it easier to create a test and leave it sitting in a preview mode. This allows users to set up a test, and have it approved by others, or be able to work on several tests over a period of time before publishing them. We've also done this to support our upcoming API. In effect this has only involved splitting step 1 and step 2 of the test creation process and putting a publish button in the middle. 

2. Random test selection Our random test selection function was not only slow, but wasn't properly supporting international languages. Basically if you can understand a language other than English (the default) you would always be served an English test before we'd check if there were any tests in other languages waiting for results. We now treat all languages equally, so we will just serve you the next test that you've said you understand. This should mean our international users get results a fair bit quicker. It also means if you speak a language other than english, we'll be asking for your help to do those other tests more often than before. This does mean that English users may be presented with non-English tests if the test owner hasn't specifically forced the test to only include users of that language.

As always, if you have any issues with the update, drop us an email at [email protected]

Thanks for your support!

I tripped over a great demo video of Five Second Test and UsabilityHub this morning and wanted to share it with everyone. It's better than our official one (no offence Matt!). Well worth a look if you have a few minutes and want to see the app in action. 

Indecision is the worst trait you can find in a startup founder. Actually, it's the worst trait you can find in anyone tasked with leading or shaping the direction of any company or project. Indecision, is simply delaying the making of a decision. Sounds reasonably obvious when you say it out load, but what isn't obvious is the implications of delaying a decision. Delaying a decision is effectively delaying work. Being indecisive is therefore no better than procrastination. Both are a barrier to getting things done. It doesn't matter whether you're running a startup, or just deciding on what to eat for lunch, indecision just makes things worse. Right now you may be stuck deciding what to eat, but in an hour's time your lunch break is over and you're bloody starving. Better to suck it up now and just have the damned noodles.

People are indecisive out of fear of making a bad decision. The logic goes that by delaying the decision, I can gather more information and then have a more informed opinion later. The information they're waiting for is really just something to either make them feel more secure in what they've already decided, or something to sway them away from something they don't want to decide. Either way, more information is unlikely to help. If you're in a position where you need to make a call now; make the call now. Looking at the menu for another ten minutes isn't going to make the noodles taste any better.

The absolute worst case is the person who delays a decision until it gets to a point that it simply becomes someone else's decision. If you meet someone like this, run the other way...especially if they're leading a team you're in. I've found myself in a position a couple of times where I've relied on someone above me in a company to make tough decisions.  In many cases the person just went on holiday, or avoided me for a week just to avoid the inevitable discussion, decision and implications. In the end, the hard tasks just fall to someone else often ill equipped to deal them. This lack of confidence in one's ability to make difficult decisions makes for poor leaders and, consequently, poor teams.

There are many reasonable sounding excuses for delays in decision making. Gathering information is one such reason and is often necessitous when making a decision. The danger in gathering too much information is when the information is being gathered simply to confirm a well known hypothesis. If it looks like someone in your team isn't pulling their weight, there is little point gathering evidence to confirm the fact. If they're not up to scratch, show them the door. The opposite case is the search for information to avoid a difficult, but necessary, choice. The reality is that if you look hard enough you can find information to confirm just about anything you like. Giving someone the opportunity to do so just gives them a chance to put weight behind a decision that everyone knows is wrong.

Another reason for indecision is when there doesn't appear to be a good option. Sometimes you're faced with a situation where you have two choices, and they're both bad. The natural inclination of most people is to simply delay making a decision in the hope that a better option comes along. Of course it's possible, but if a better option doesn't surface, you've likely left yourself with the same two choices you started with...except now you're a month poorer as well. Sometimes you just have to play the cards you're dealt.

Some time ago I watched a great video on youtube about indecision and inaction over global warming. The premise of the video is that we can act or not act, and global warming could be true or not true. There are therefore 4 possible outcomes, the best case being we act on global warming and it turns out to be true, and the worst case is that we don't act and it also turns out to be true. The interesting part about the video in this context, is arriving at how to decide if you should act.. 

Imagine we're provided with a situation where we may or may not have a major problem in our software; we'll use the infamous Y2K bug as an example. If we spend a heap of money investigating if our software is affected and it IS then we're all thrilled that we avoided disaster. Good decision! If it turns out that we weren't affected...well at least we know! That's still pretty good....even if it did cost us a truck load of time and money.

Now, let's imagine we didn't do anything. NYE rocks around and we're out partying the night away. Barry, our sysadmin calls us at midnight with the news. If everything is ok we all high-five each other and get on with the partying. If, on the other hand, all of our software is now dead, banks are going belly up, planes are crashing, toasters are exploding...well...we'd probably be in a really bad place. Here's a handy little chart with the possible outcomes from a situation like this.

In essence, when you have an unknown outcome it's always better to act than it is to not act. If you don't act and things go bad, they can go really bad. So what's this got to do with indecision? Well, indecision is the same as not acting. By not making a decision, you're in effect choosing the "don't act" column. By not acting, you're rolling the dice and hoping for the best, you're giving up any say in the matter, you're relinquishing control to some external power, you're crossing your fingers and toes. This isn't the way to deal with global warming, and it isn't the right way to run your business. If you have control, use it.

Difficult situations don't disappear. They just get worse. If you've got a bad employee causing problems, delaying the hard decision to give him the boot just increases the chances of him affecting those around him. If your website is losing you money, delaying the decision to pull the pin will just cost you even more. Decide early, and act swiftly.

So what's the worst that can happen if you make the wrong decision? The fact that you decided to do it means that it was the right decision at the time with the information you had. So it only became a bad decision when unknowns surfaced, or when something changed. When that happens, you simply make a new decision. That may be that you alter what you were doing slightly, or it may be that you scrap it in favour of a new path. Either way, by making a decision you forced an outcome. If you hadn't acted, those unknowns would still be unknown. By making decisions constantly based on the information available, you uncover newer information more quickly. Inaction rarely provides anything actionable.

Very rarely, you can make a call which turns out so horribly wrong that you wonder how you could ever have made such a stupid mistake. When this happens, talk it out. If your customers are pissed at you, get on the phone, email, twitter and talk to them. Apologise for your mistake and ask what you can do to make it better. If you broke something, let people know, and get help to fix it. It is highly unlikely that you'll ever make a mistake that you can't recover from. Put you hand up, own the error and start talking about how to fix it. Taking actions sometimes means taking risks, but without taking risks you will never achieve something great.

So when you're faced with a decision, look at your options, talk it over, experiment, research and ponder...but when you're done, make a decision. The sooner you get moving, the sooner you find out if you were right or not. The earlier you act, the more choices you will likely have available. Leave your decisions until the last minute, and you'll often find the options have dwindled significantly. 

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at [email protected] or even Twitter @alandownie

Start at Part 1 of Optimize, don't Organize here

7. Sticky notes, and why they rock.

If you have a wall next to you (or even that whiteboard I told you not to use), sticky notes may well be your saviour.

It’s harder to escape your decisions.

A sticky note wall tends to promote a “first in, first out” mentality. The oldest and most important tasks tend to end up at the top of the list rather than at the bottom. For some reason when you added that task to the top, you considered it to be the most important. It probably still is, even if you don’t feel like doing it. Putting it off isn’t as easy as moving it to the bottom of the list, at least not unless you re-sort and re-evaluate the entire list (and even that’s not a bad thing).

Just because it’s new doesn’t make it more important.

We have a tendency to think that new tasks are more important than old ones. Someone jumps on the phone and tells us they need something done by the end of the day so we drop everything to get it done, forgetting that we have two other tasks that also need doing by the end of the day. Just because it’s newer, doesn’t make it more important. If anything, our older tasks should take priority. The sticky note list will tend to force you to put newer tasks below older ones. And if you really need to place it above your existing items, you have to be damned certain you want to raise the limit on “importance”, because eventually you’re going to run out of “higher” on your wall or whiteboard.

Sticky notes are only semi-permanent

My sticky notes are on a painted wall. The glue lasts about three or four weeks before the heater (or air-con) blows them off the wall. In reality, if I haven’t done a task that’s been on my list for three weeks, I’m probably not ever going to do it. When your notes fall on the floor, it forces you to re-evaluate them. Is this task worth rewriting on a new note, or should I just bin it?

Sticky notes are real

Taking down a task is a reward in itself. The little square of paper has texture and colour. If it’s been on your wall for a few weeks, you may have even gotten used to the quirkiness of whatever you wrote. It’s a real thing that existed in your little work space. It gives the task life and a sense of reality. Best of all, they’re something you can screw up into a tiny ball and take a shot at the nearest bin (or colleague’s head, whichever works). 

Previous chapters:

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at [email protected] or even Twitter @alandownie

Start at Part 1 of Optimize, don't Organize here

As a rule, task lists don’t work. They become cluttered, out of date and full of things we never intend on doing. 

Why digital lists don’t work.

Digital lists are too easy to add to. We add things that aren’t important, things that we don’t need to remember and things we feel we “should” do, but never will. Worse than that is that tasks are too easy to strike off. With a click of a mouse or a swipe of a finger we can permanently erase our failure to complete something that we originally thought was important enough to add in the first place.  With every second person owning a smart phone, digital tasks lists are popular for their portability and convenience. Whilst it may be great to remember what you needed to buy down the shop, organizing your work in a digital list is always going to end in tears. If it’s too easy to fill with clutter, and too easy to remove our failures, we won’t trust it. If we don’t trust it, we won’t use it.

Why pen and paper doesn’t work.

I have too many notebooks. I take notes in meetings, I take notes on the phone and I take notes when I’m programming. I don’t need a todo list on my desk as well. Pen and paper tasks lists are also the worst for maintainability. As your tasks are crossed off your list becomes more and more messy. This either forces you to regularly rewrite your list, or to throw it out entirely. You can’t sort, you can’t undo, you scribble phone messages in the corner and worst of all you most likely can’t read your own writing. We write something down in a hurry and are later left wondering, “what’s ‘sulmif buffon’?”

Why whiteboards don’t work.

Whiteboards are the worst. Even someone with the best penmanship can’t write for shit on a whiteboard. The whiteboard suffers from all the same problems as pen and paper but without any of benefits. Possibly the only thing in favour of a whiteboard is also its biggest drawback - the ability to erase. It might be handy to be scrub off that completed task, but it’s also just as easy to accidently remove your whole weeks work. Somewhat contradictorily, whiteboards are also a magnet for old information. Unlike a paper list which we may eventually throw out, a whiteboard tends to collect things that nobody ever thinks to wipe off. Out of date information is the worst kind.

Coming up:

7 - Sticky notes, and why they rock.