Because machines still need humans
Monthly Archives: July 2011
July 13, 2011Posted by on
The phenomenal increase in free and pay-per-usage SaaS offerings in recent years has made it so insanely simple to build new websites starting only with…well, starting with absolutely nothing.
In the old days (cue Abe Simpson voice), developing and deploying a new website required the purchase of actual servers, or at least the rental of some machines from an ISP. And if there was more than one programmer involved, the very idea of them working in a truly distributed manner as seamlessly as if they were sitting next to each other sounded just a little too futuristic.
How things have changed! Now a programmer can conceive of an idea, collaborate with people who live hours away and deploy a website for almost nothing. Best of all, there are also plenty of SaaS tools available that enable the work to be done in a truly professional manner.
Build, Test, Deploy
Amazon recently launched a free tier that will allow you to run a Linux VM in their EC2 cloud for free. For an entire year. If that isn’t enough, you can also avail of plenty of free time with their load balancers, storage systems like S3, EBS and SimpleDB, not to mention their messaging and monitoring services. Microsoft does offer a free 90-day trial for its Azure cloud platform, but the last time I checked, 365 > 90. For now, Amazon wins.
Now you’ve got a place to host your website. It might not be a powerful server, but it gets you up and running quickly.
Grab that Awesome Domain Name
If you stay on the AWS free tier then you’ll be stuck with an ugly DNS name like
ec2-11-22-33-44.compute-1.amazonaws.com. That sucks for two reasons. First, it’s completely forgettable and useless as a real website URL. Secondly, and more importantly, if your EC2 instance reboots, then the name will change, so you’ll need to hook up your image to register its IP address dynamically with a service like FreeDNS (or pay for Amazon’s Route 53 service for the not-very-scary price of $1 per month).
Add Source Code Control
At this point, your website is up and running and you still haven’t spent a dime on hardware! But your buddy from college has just offered to help write some code with you, so now you’ve got to start acting professional about source code management. So, you look around for a free SCM tool online but decide to go all-out and pay for a GitHub account. You sign up for the $12/month small plan and instantly feel weird forking over money for the first time since you started the project.
Communicate and Collaborate
Now a real company is forming. You’ve got thousands of registered users, and you’ve had to deploy more EC2 instances to handle the website load. You’ve also got more programmers working with you, and communication with them is vital.
This is where services like DropBox, Skype, Google Docs and Mozy become indispensible. It helps that their free tiers are quite generous and should support a small team of programmers with ease. Now you’ve got a virtual IT department on staff, keeping things working smoothly in the background.
Dive Into Load Testing
Now you’re sucking diesel. Your web traffic stats are looking better each day since you were slashdotted, and you want to make sure you can handle even more traffic so that your potential investors don’t see any downtime. So, do you buy a whole rack of high-performance machines with which to test your system under extreme load?
Heck, no! Why start buying hardware now? If you’ve got the time and chops to do it, you can just spin up a bunch of Amazon AMIs and have them push your system to the limit – and then spin them right back down again, paying only for the time they were running. However, if you’re too busy to build all the load tests yourself, you could have a company like uTest create and run them for you.
The Hidden Benefit
There’s more to this than just the happy avoidance of hardware purchasing and an affordable go-to-market strategy. There’s a frequently overlooked but very real engineering benefit to having the development team begin life in this manner: it makes the engineers become the operations team, deploying their own software and keeping it healthy themselves. There are plenty of companies that suffer because of a chasm existing between engineering and operations, causing coders to dump software over the fence, leaving IT people unfamiliar with its architecture responsible for deploying and monitoring it.
When the organization grows to the point where a separate operations team is required, a hybrid version of this approach can also work really well.
If you have an idea for a great website or online service, you have no excuse for not signing up for some free SaaS products right now and getting it out there.
If you build it, they will come. And you can start for free.
July 2, 2011Posted by on
Your users are complaining about an unusable feature in your product. It’s so unintuitive and impossible to understand that they are calling it a “bug” in many angry emails to your support staff.
When the discussion reaches a coder, the issue suddenly gets reclassified as a “badly-designed, but correctly functioning feature”. Out of nowhere, they have rid the problem of its shameful “bug” association and made the whole situation seem a lot less troubling.
Coders fiercely argue that if the feature works as intended — regardless of how unusable it may be — then it is not a bug.
It doesn’t matter that your users can’t figure out what the heck to do with it. Or worse, they make incorrect assumptions about how it should work and get totally surprised by some weird side-effects it causes. For a coder, a bug is something completely different, like an exception or a computation error.
The distinction between a “terribly-designed but correctly-implemented feature” and a “bug” exists only in the coder’s mind. It is a distinction they create due to their professional immaturity. What they are really saying is, “Well, someone else may have designed it badly but I implemented it correctly.” Their focus is on their own priorities. The success of the team, the product and the company are secondary.
Allowing a usability issue’s seriousness to be disregarded in this manner is harmful. Apart from the fact that the issue will very likely get pushed to the bottom of the priority queue, the team could also start to consider your user’s opinions as being less valid than their own. Once that happens, the inmates will be running the asylum. You’ll have a system built by programmers, for programmers.
Engineers however will listen to their user’s complaints and quickly agree that it’s a bug. No debate. If the feature doesn’t work for the users, then it doesn’t work at all. What matters is that it gets fixed.
So how can you help a coder change their attitude towards usability bugs? One method is to have them sit and watch a new user flail around trying to use the feature in question.
But my favorite approach takes almost no effort or time at all. Just ask them,
If this was your competitor’s product, would you still defend it as a working feature?