If you write software for a living and you’re located in Silicon Valley, you have your pick of employment options at an array of tech start-ups — yes, even in this economy. When a recruiter’s pitch is: “Wanna bro down and crush some code?” — like San Francisco-based Klout’s was — you get a sense of what that company is looking for. If you’re a woman, it’s not you.

That’s pretty sad, but it’s not all bad. As a woman and a software developer, crossing Klout off the list of places where I might work helps me narrow my options. I’d rather find out that an employer glorifies young dudes before I take a position than afterward.

In war for talent, ‘brogrammers’ will be losers - Gina Trapani

Ugh, what a tough issue. I’ve got a bit of a background in sociology/gender issues, and I see both sides of the “women in tech” issue. It’s not exactly an evil-genius-sinister cause, but it does exist, is a serious issue, and there’s no easy fix. It’s a recipe for problems.

I’ve seen another side of this too. I went to a women in tech event to meet a friend there. There were a very few guys there, almost the opposite of a typical tech meetup. I got there early, so I started introducing myself and chatting the same way I do at the many events I go to. I was immediately accused of being there to pick up women. I’m not pointing fingers and judging, but it does speak to the fact that there’s a lot of pressure around this issue and it means some things can get misinterpreted. Things aren’t always what they seem.

I agree with Gina’s core idea — anyone who hires based on anything other than the ability to produce results is going to put a ceiling on their results. She is 100% spot-on with this idea. It’s practically a tautology, something that even the bro-iest of brogrammers should be able to comprehend.

I am sad to see that Klout has gotten dragged in. I’ve been fortunate enough to work (albeit briefly) with Joe Fernandez, the CEO at Klout. Especially considering the success that he and Klout have achieved, he is one of the nicest and most thoughtful CEOs in the tech scene, and is a great case study against the myth that to be successful in business, it requires being an alpha male jerk. I don’t believe that Klout has the type of culture that’s being suggested, the “frat-house fun” culture.

“Bro” has taken on widespread ironic use on the internet, and it’s really hard to judge irony via text. I believe that if Joe had thought that “bro” would offend women, he would have struck it down immediately.

It’s certainly not a good idea to do things that can be misconstrued as sexist (like the hiring headline that was used), and sometimes good people do boneheaded things. That being said, things aren’t always what they seem, and I think it’s a mistake to make assumptions. Especially in this specific case.

We’re doing what we can at Cloudspace. One of our engineers, Sarah Sheehan, has mentioned to the Cloudspace managers that she knows females who want to learn how to code, but get a “weird” feeling about learning. This is an example of the subtle causes and effects of gender inequality in our industry — it’s not always the sort of flagrant Mad Men-issues that most people think of. An awkward feeling multiplied across a large enough group of people can have the gender effects that we see in tech. So, with our support, she’s working on a Rails Girls-style workshop to help get women started.

Is there gender inequality in the tech industry (as well as others)? Yes. But in the case of Klout, I think that things aren’t what they seem.

Bad: Churn can kill you, or at least your market cap

If you are building a SaaS business, churn is your enemy. Most public SaaS companies report their monthly churn rate, either as a percentage of revenue or actual customers gained/lost. These rates depend on the type of business – 2% monthly churn is in the “tolerable range” according to many experts.

Patrick is right. Churn is terrible for a business model that relies on long-term relationships. If you’re a car dealership, churn isn’t as big of a deal, because purchases are discrete events and only occur about once every 7 years. So if you screw something up, you have a lot of time to correct the problem (or at least enjoy many years where you can still produce a lot of profit).

In SaaS companies, one way of thinking about churn is in the context of switching costs and sunk costs. One example of this is an API, or rather what APIs represent — money and time spent on integrations. APIs are a form of competitive moat that protect a business thanks to switching and sunk costs — if customers spend time and money integrating with your system, they’re not going to switch as easily.

Note: I’m not encouraging lock in as a good business practice, but as an investor, it’s worth considering the switching costs at a company (both switching to and from). Lock in is actually something we strongly avoid at Cloudspace — for one example, by not locking clients into fixed development schedules, we earn our business every week, and that ensures we have the right incentives. Then again, we’re less Software-as-a-Service, and more like Skills-as-a-Service (or maybe Brains-as-a-Service), but I digress. If you’re a good company and you treat customers right, it can buy you a lower rate of churn and lock in isn’t quite an issue.

This all being said, inverting the problem is interesting. Churn at your own company is bad, no doubt. But, if you’re competing against an existing SaaS company, you want to increase your competitor’s churn. One strategy for doing this is to build easy-to-use importers that import a customer’s data from their system into yours. By reducing the cost of switching to (or at least testing out) your service, you can grease the adoption funnel. As far as I know, music streaming services (Spoitfy, Rdio, etc) have never done this. I don’t understand why. Eventually it would produce a bit of an arms race, but that’s the nature of competition.

To be fair, a company like SugarCRM vs SalesForce has more complex data structures, so this isn’t quite as easy as a SaaS with simple data structures like playlists, but there are still strategies for dealing with this. And of course, there are strategies to defend against this, too

If you want to learn more about APIs, check out the O’Reilly API strategy book or talk to my friends at Mashery, who are outstandingly good with these things.

The big thing that I think is missing from Carlos’s post is context. Techies tend to see the value quickly, but it’s good for business-types to know why a new tool is helpful to the business, instead of just a passing fad. Virtual machines (VMs) and automated configuration (Chef) are very useful, and like Voltron, they’re even more powerful when combined.</80s-reference>

Starting from scratch

Here’s a story I heard about another development company who had a laptop stolen (full disclosure: I didn’t steal it). Computers can get stolen, or they can break in any number of ways… c’est la vie. My issue isn’t that they had something bad happen, my issue is their backup plan, or rather, a lack of one.

They ended up spending a week where they couldn’t do any work because they were rebuilding their development environment after buying a new machine. Imagine if that had happened only a day or two before a big release!

Contrast this against something that happened recently at Cloudspace – one of our engineers had his laptop die on him. After a quick trip to the store, and copying over the VM onto the new machine, he was ready to work again. Total time: 2 hours.

It’s the difference between “oh no!” and “OH YEAH!”

Not to mention that if you’re a growing team, it’s a lot nicer to have a simple setup so that people don’t spend time configuring their machines when you hire them.

So VMs and automated configuration can help as an insurance policy in case things go wrong. They can also help prevent things from going wrong…

What’s the difference between me and you?

Software is complex. We know this. A full development stack (even for a simple app) has many moving parts:

1. Operating System
2. Filesystem
3. Web server
4. Application code
5. Libraries
6. Databases
7. Queues
8. Information Retrieval/Search engine
9. Monitoring

Anyone who has been developing long enough has run into some weird bug that only occurred on a specific configuration, or a specific version of software.

When you’re developing locally (testing code on the computer in front of you), it’s rare to have the exact same setup that you do in production. Compounding the problem is that many companies will have applications with slightly different components. It would be nice if every application in a company used the exact same stack — in the real world we know this is not the case. Developers have to be able to work on different applications, or you end up with massive team bloat, and your operations budget goes up.

So developers have a single machine, with one configuration, but they’ve got to work on several applications that have different configurations — this means that developers run code on their machines in a different stack than the production server. Even a minor build difference — let’s say 5.0.1 versus 5.0.2 — can produce the dreaded “well it runs on my machine!” followed by hours or days of wasted time to track down a mysterious bug (costing you money, as well as the loss of forward progress). This is supposed to be one of the advantages of SaaS — you don’t have to worry as much about the configuration of different machines for your customers. But you do have to be aware about the configuration for your developers.

By developing in a virtual machine, you can replicate a production environment. Note that I didn’t say a production server – I said environment. Any complex application is going to have several servers: web heads; database servers (masters and slaves); queues; cache servers; the list goes on. You can run an entire architecture from a single laptop, which means that mystery bugs get discovered and fixed sooner. Time saved, money saved, reputation saved.

One other way around this issue is having a staging environment that is a copy of production, also hosted in the cloud. I’m not anti-staging environments, but there are limits. I’ve seen other teams where people have to wait because someone else is using a staging server. It’s like these teams are trying to slow themselves down.

By taking advantage of virtualization and automated configuration, everyone gets their own staging environment without the added cost. Imagine multiplying your hosting cost by the number of developers!

Not to mention that if you had all these different machines running the same setup, you’d need something like Chef to manage the configuration of them all (or your Ops team will waste time and money doing it all by hand). Just another way that VMs and automation play well together.

Bonus Employee Happiness Factor: because you can run a production environment contained within another computer, it doesn’t matter what that outer computer is. So if one developer has to run OSX, but another developer couldn’t imagine life without Ubuntu, it doesn’t matter. They can each use whatever OS they want and whatever text editor they want. They’ll still be building software under the same conditions.

Automated configuration: the multiplier effect

The list of ways that automated configuration has a multiplier effect is significant.

1. Development servers
2. Staging servers
3. Production servers
4. Continuous Integration & Continuous Delivery servers
5. Hot copies. Large architectures have servers that are running production code, but not handling production traffic, that can be switched to if a live production server dies.
6. Crash recovery. If a production server dies, rebuilding by hand takes time. Automating this makes things quicker, and removes the risk that a step might be skipped.
7. Software upgrades. What happens when you need to update the OS on 100 servers?

All of these situations are going to benefit from having automated configuration — it’s faster to set them up, and it keeps things consistent, which we engineering types love!

If you’re interested more information about how Cloudspace can increase your pace and quality of development, get in touch with me: tim@cloudspace.com

He described his product as being something that is at the intersection of technology and food, taking some of the more advanced ideas of how tech affects our daily lives, and making it available to people who are really into food.

The most interesting things are on the leading edge — where the early adopters live (food, tech, music, whatever). The useful things eventually make their way out of early-adopter-ville (where they may get lost in the noise), into the mainstream. But while they’re still on the leading edge, it’s only available to people who spend the time and energy to be an early adopter.

Hence his problem. The previous version of his product was aimed at the intersection of two big trends, but it required the person be on the leading edge of both of them — that takes a lot of time and energy, more than just being a solo-early adopter. If early adopters are 10% of the total market, and you’re aiming at more than one type of early adopter, then you’re looking at 10% of 10% — a small addressable market.

I’m a huge advocate of doing user testing — even at the earliest level. One of my favorite stories on the subject is of a team that was working on a product that involved people recording data into a mobile app throughout the day. In order to do a bare-minimum proof-of-concept, they gave people small notebooks and a pen, and asked them to write down the data as it happened during the day. It cost them around $10 per person, and they were able to find out that people felt it was worth doing the activity (which is a requirement for everything else to work).

While testing a product hypothesis like this can be done at the very early stages, you’ll need more sophisticated tools as you progress. Once you’re at the point where you’ve got an app (web or mobile) product, user testing sites can be cheap and helpful ways to get feedback from people who you might not ordinarily interview. Keep in mind, it’s best to try different testing companies if you’re doing a large number of tests. Different companies have different ways of assigning people to tests, so the more companies you work with, the more likely you are to avoid any group bias.

If you’re just getting started at the mockup stage, Verify is a great starting point to get feedback on mockups and static content. The price of admission is worth the time you’d spend finding people on Craigslist and coordinating your own review of mockups.

The best site to get started with user testing of a web app is, in fact, UserTesting.com. The value of having video and audio is worth the peak price of $39 for at least a few tests. I know one team that revised one big UI interaction based on the first video, because the user did something that was totally reasonable, but was not what they expected.

TryMyUI is another site that has a similar model to UserTesting.com, and is a good starting point. $35 for a single test, so you can decide between TryMyUI and UserTesting.com to see which site you prefer. (Although they’re offering the first test free right now).

Once you get a few initial tests done, and you get a feeling for how to get the best information from your test group, you can move on to some heavier services.

Userlytics is aimed at larger groups who want to do several tests. They include video of the user’s face, some additional narrative and highlighting which is great if you’re looking to dive in a bit deeper, but you aren’t ready to bring in a professional UX team yet.

YouEye is similar to Userlytics in that they offer video of the user, but they have a package approach that’s better once you start using the site heavily.

Beyond these services, you want to start bringing in experts. Teams like Adaptive Path and EchoUser have seen it all and can take a deeper dive on your product as a whole, instead of the component-at-a-time approach that these self-service sites tend to focus on.

The old way of collecting information is one that many sites still attempt: collecting all of this information up-front:

Registration forms like this often encourage users to give up during registration, meaning low user counts, low ad revenue, and no opportunity to upsell to other products later.

LinkedIn did a good job innovating in this respect. They don’t require a full profile during registration, but gently remind users that they should fill out more information:

CommonRed is a social networking startup that’s using the same technique as LinkedIn, but has taken it further. In addition to the gentle nudge from “% Profile Complete”, they have a sidebar widget that asks users simple questions.

CommonRed is a networking startup, so they ask simple questions about hobbies that users can connect over. As a user clicks answers, each question fades away and is replaced by another.

This interaction is valuable. Not only does it get more users into your product, but it also gets you more information about those users in a pain-free way (I’ve personally answered at least 10 of these because I found some of the oddball questions interesting, and I wondered what was coming next). Think of how it can be used in your own product: gauging interest in new features, collecting demographic information for marketing, or even setting preferences.

This tip is courtesy of Hotel Tonight, who sent me an email today demonstrating the technique, and inspiring the post.

Step 1

Send your users an email with a tantalizing subject line

More free money? Sure I’ll open this. I signed up for the product to save money on hotels, so linking the subject line directly to that core value is effective.

Step 2

Follow through on that offer quickly

Step 3

Remind users that they need to update their app in order to get the benefit.

Step 4

Wait for people to see what you did there, and then blog about it, driving more users to your app.

See what I did there?

This is why I’m so pleased to see my friends at Lumatic (the company formerly known as Omniar) taking advantage of this for their product and UX.

They built a static HTML version of the product that simulates many of the user interactions and the interface. At the end, they use a free survey from SurveyMonkey to collect feedback. Even better, they’re building a mobile app, and have still prototyped using HTML.

This is a great way of collecting thoughts from users, instead of only sitting down with users one-on-one (which they’re also doing). They can find out if there are missing features, or if people are interested in the features that are there.

I’ve seen other effective prototypes done using paper — if you’re going to be collecting information from users that might have privacy implications, you can test out resistance to it with a sheet of paper (or another free SurveyMonkey form). Another startup gave potential users a small notebook to see if they would write their thoughts during the day on a subject (which simulated a part of their upcoming product).

Figure out what’s most risky in your new venture, then find a way of cheaply testing it so you can reduce the risk. Feel free to discuss in the comments, or email me if you have questions — tim @ cloudspace.com