a little madness

I see it time and time again in comparisons of software products where one or more of the options is open source. Someone chimes in with a comment along the lines of:

Why pay for product X when I can get open source Y for free?

My response to this is simple: X != Y. Price is a very primitive way to choose software. Differences in price, even when one price is zero, are often insignificant when compared to other factors. Unfortunately, these other factors aren’t so easily boiled down to a single number, so the lazy consumer does not pay them full heed.

If we could boil the other factors down to a single number, what would it look like? Well, allow me to present a gross simplification. Suppose you are a company comparing two tools: one open source, and a commercial alternative that costs $500/seat/year. The end goal of the both tools is to make the user more productive, i.e. to save them time. For argument’s sake, say the average user’s time costs the company $100,000/year. For the commercial software to be worth the cost, it needs to improve the user’s productivity (relative to the open source tool) by about 0.5% over all. Put another way, it needs to save the user around 12 minutes each week. This is a small ask, particularly if the tool is something the user relies on heavily to get their job done.

Sure, these numbers are pulled out of the air, but they are not that far removed from reality. Skilled workers can easily cost more than $100,000/year, and a heck of a lot of software is priced under $500/seat/year. The real point is that an increase in productivity is far more important than saving on licensing costs (except perhaps for software priced “by the enterprise, for the enterprise”).

There is also a sad flip side to this: open source has a whole lot more going for it than the price. Factors such as transparency, community and extensibility are usually far more important than saving a few dollars up front. Not to mention the fact that the most productive tool for you may be an open source alternative. By no means am I saying to avoid open source. But do yourself a favour: put in a bit more effort and make your choices for the right reasons.

Fresh out of a Computer Science degree at uni, I hit the job market looking, naturally, for the best job I could find. I immediately ruled out moving into big business (think banking, insurance) and the consulting roles that tend to take you to such places. I wanted to work with technology I could enjoy, on new projects, churning out interesting “stuff”. That is what led me to the wonderful world of the VC-funded startup.

There are many great things about startups:

1. New projects: by their very nature, startups have brand new projects to work on. We all know that starting from scratch is much more stimulating and fun than maintaining a 30-year-old COBOL codebase.
2. Great people: because they have interesting projects and questionable job security, startups tend to attract people with a real interest in technology. You don’t get people who moved into “IT” as a career strategy, you get people who love what they do.
3. Great atmosphere: partly because of 1. and 2., but also because of their small size and youth, startups often have a great feel. They haven’t had time to develop the painful politics and beuraucracy of older, larger companies. Hopefully they never will!
4. No customers: when you’re just starting out, there are none of those annoying end-users to pester you with support questions and Real World problems. You can just code away in your own little world.

So I jumped aboard the VC-funded startup roller-coaster, and I had a great time. I lost my job a couple of times, but there were always new ventures to start on. I had a ton of fun and I learned heaps.

But something did start to bug me. I poured my efforts into these ventures and their projects, and even though the technology was fun, there was somewhat of a hollow feeling. The problem was that all of this effort was going to waste: without customers everything I created was consigned to obscurity. Of course the startups planned to get customers, and lots of them, but the business model was the classic boom-or-bust strategy. Either we would “disrupt” the world, or we would fade into oblivion. Of course, the odds lean heavily towards the latter.

So this supposed advantage of not having to worry about customers turned out to be the one great drawback of working for startup ventures. Jeff Atwood touches on it in his post Shipping Isn’t Enough:

How many users actually use your application? Now that’s the ultimate metric of success.

I achieved plenty in terms of development as a programmer, and I even managed to do some pretty good work (I hope!). But at the end of the day, I didn’t have the sense of achievement that only comes from creating something that other people use.

However, I have not given the startup game away :). I realised that you can have all the advantages, just with a different strategy. So at Zutubi we’re not planning to “disrupt” anyone. We just make software that people love to use, and grow organically off the back of that. And for once, I have Real Customers that use my software, and I interact with them closely. Who would have thought it: I love dealing with customers! Not because they pay (though I thank them for that ;)), but because every time I learn of someone new using our software, I get that sense of achievement I had been looking for.

Even while I wrote this entry, an email landed from a customer commenting on how they loved the user experience of Pulse. Honestly, it does not get any better than that!

People regularly write about good and bad tech interview questions. Certain companies are famous for their interviews, there are books and websites full of such questions, and there are countless blogs on the topic. Still, many of the questions I have heard asked and seen quoted in blogs are just plain ordinary. Heck, even questions I have used myself look worse to me as time goes on.

Certain common question types are useful, such as:

• Simple coding tasks: as a quick screen. If the candidate can’t reverse a list, it’s an immediate no.
• Problem-solving puzzles: made famous by Microsoft. A good puzzle or two can be a fun way to find out how the candidate approaches a problem.

However, the quick screen doesn’t do the hard job of separating decent coders and great coders. And it can be hard to draw conclusions from a puzzle question: is the candidate just a fan of puzzles (i.e. clued in to the tricks)? I think part of the problem is we need to look at the issue a slightly different way. These questions are trying to emulate the challenges of the job, but they fall short in two key ways:

1. To fit the task into a 10 minute question, it is scaled down to a toy size. Nice for an exercise, but not very realistic.
2. The interviewers themselves know the answer, giving them a position of power over the candidate. They may be biased towards their known answer (despite a unique alternative from the candidate). They could either lead or intimidate the candidate from this position.

So what kind of question can be used to overcome these shortfalls? Simple: a question with no answer. Or, at least, a question that you don’t yet have an answer to. Every day on the job we run across these problems, and have to solve them. It’s the essence of the job. And we solve them together, not as individuals, and certainly not with an all-knowing interviewer smugly sitting on the perfect solution.

Sure, this sort of question is not nice and clean to ask. As the interviewer, you have to be willing to be as out of depth as the candidate. The benefit is you are now working on a level playing field together with the candidate, just as you would if they were hired. This both adds realism and allows you to assess their ability to fit in with the team. You can brainstorm solutions, debate alternatives, hit dead ends and make breakthroughs together. You may have no answer, you may come across many, it’s not really important. Tomorrow always brings a new problem.

So how do you come up with these questions? One possibility is harvesting them from real life examples. Is there a problem you are struggling with today? If it makes sense in isolation, it could be a perfect candidate. Is there a design issue you run across every now and again, and never seem to have a good answer? Note it down. If you’re really stuck, try what we did a couple of times at my last company. Pick a random question out of a programming competition archive: one that you have never seen before. Take it into the interview blind, don’t have a head start on the candidate. Some realism is lost, but many of the benefits remain.

Happy interviewing!

Most software companies know that support is important. Many wax lyrical about the importance of the customer. Few deliver. If only they’d abide by some basic rules for support:

1. Be Honest: don’t try to pull one over your customer. If you made a mistake, or they have found a bug, acknowledge it.
2. Believe: no matter how far-fetched the user’s problem/claim, take it at face value. Think you’re certain it’s user error? Test it anyway. Nothing is worse than being fobbed off as a stupid user when you’ve found a real problem.
3. Respect: your customers are not idiots (they chose your excellent product, right?). There is no such thing as a stupid question: we’ve all asked “obvious” things at some time. Treat the request and the person with respect.
4. Respond: monitor support requests frequently, and respond as soon as possible. If a full answer will take a significant amount of time, respond to let the customer know you are on to it. Nobody likes to feel ignored!
5. Track: never, ever allow yourself to lose track of a support request. Use a proper tracking system to ensure all problems are stored and dealt with. Lose the request and you lose the customer.
6. Learn: don’t just solve the short term problem. Use support requests as a guide to improve your software and documentation. Getting asked a “simple” question a lot? Add an FAQ, or just improve the interface. Support is not just a time drain: it’s a valuable source of feedback.
7. Apologise: your customers shouldn’t have to bother with support requests, they just want things to work. Let them know you’re sorry that you’ve wasted their time. No need to grovel, keep it genuine.
8. Thank: many customers that encounter a problem will just walk away (probably to the competition). When customers take the effort to lodge a support request, thank them for their feedback. It’s just polite.
9. Follow Through: don’t pass the support buck from one employee to another. If you respond to the request follow through. Get advice where you need to, but take the issue to completion.
10. Be Certain: when you answer a support request, you must know what you are talking about. All but trivial requests will require real product knowledge. All employees (e.g. developers) should be available to help answer support requests.

Really, support is mostly about attitude: care about your customers. Understand that support, though time consuming, is helping you make your product better.