Tue 31 Jan
2012

Links of the Week 7

Posted at 12:50 PM by Cameron Westland in Links

This Week: Testing, Front-End, Back-End, Reference, Teamwork

Testing

commondream/tconsole

Seems like a great way to remove the startup overhead without hassling with the configuration.

Taming a Capybara - Emmanuel Oga's Software and Stuff

More on getting capybara to run smoothly. I'm glad the community is sharing these sorts of things, we're definitely benefiting from it.

The evil unit test

I 100% advocate testing behaviour over implementation. That doesn't mean mocking is bad. It means you need to use it to mock out dependencies.

Front-End

HTML5 Please - Use the new and shiny responsibly

A good way to lookup how pervasive the feature you're about to use is. Ideally you'd just use Modernizr and make your application work either way.

Gettext style i18n for Modern JavaScript Apps

I know of a few front-end heavy projects that should be using something like this.

Color - Method of Action

Another cool game designed to teach developers about design.

Back-End

Inject that Rails Configuration Dependency

I love any article that helps me understand dependency injection more. We've recently started using our config more as we're connecting multiple applications together. This does make testing bothersome. Great tip.

On My iPad

A seriously great list of applications. Fraser is definitely an iPad expert.

PUT or POST: The REST of the Story

Great resource for API developers out there. Are all your PUT requests Idempotent?

My five favourite "hidden" features in Rails 3.2

Some of the lesser known features in Rails 3.2

Reference

Node.js reference

A more readable form of the Node.js documentation.

The Little Redis Book

I'm going to use Redis for something one of these days. Saved for reference.

Teamwork

Scaling GitHub

Zach shows why GitHub is so awesome.

Why Software Development Estimations Are Regularly Off

An fresh perspective on why software estimates are bad bad mojo.

Mon 23 Jan
2012

Links of the Week 6

Posted at 9:07 AM by Cameron Westland Links

This Week: Movies!, Gems, Essential Geek Reading, Reference, Teamwork

Movies!

Wat

Seriously hilarious. Also an awesome catalog of e-learning videos. Why didn't I know about this sooner?

Gems

acts_as_api

Putting view logic in your model is never a good idea. This is an anti-pattern. Use a presenter to handle this.

Factory Girl 2.5 Gets Custom Constructors

While we heavily use Factory Girl I can't help but think that it keeps getting more complicated. We're relying on stubs a lot more these days.

Essential Geek Reading

The Trello Tech Stack

I love this stack. Although I'm not completely sold on 100% single page apps things like pushState are slowly convincing me.

Distraction is a Symptom of a Deeper Problem: The Convenience Principle and the Destruction of American Productivity

We believe the right kind of distraction is a symptom that knowledge hasn't been properly socialized on the team. Cross team interruptions however are definitely bad.

An object is not a hash

I can see a whole new generation of javascript injection/cross site scripting issues because of this.

Reference

JSRef - JavaScript Reference Manual

Seems like a YARD style reference for JavaScript built on top of the MDN

How to run rvm scripts as cron jobs?

Dave was having problems with this one earlier this week.

Teamwork

visionmedia/git-extras

Seems like there are some good commands in here for working with teams.

Wed 18 Jan
2012

Advice for Lean Startup Machine Toronto Attendees

Posted at 4:38 PM by Max Cameron Customer Development

Last year I flew down to Boston with some colleagues and we participated in Lean Startup Machine. I’m not lying when I say it changed my life. All of a sudden, I could separate and connect the theory of customer development from its practice. But more importantly, I was stripped of the fear (and any other excuse) of finding customers and trying to sell them a product.

I also learned a ton about customer development and I've been trying to share those lessons ever since. After that experience, I immediately knew that Toronto needed this event. This year, I’ve been lucky enough to be acting as an LSMTO event organizer and participate as a mentor. And because of my prior experience attending as a participant, I’d like to share what I learned last year so you can make the most out of your weekend.

Joining a Team

This is the first big decision you’re going to make when you show up at LSM. A few people have asked me if they should try to pitch the idea they’re working on, or if they should join another project. My advice to them has always been the same; whether you’re pitching your own idea or joining another team, there are three things to keep in mind:

• Customers - Choose a product that has customers who will be accessible to you over the weekend. Definitely avoid projects that can only be sold to the VP Marketing at fortune 500 companies. They don’t work weekends.
• Agility - Choose a project you’re not afraid to change. This might be a good argument not to pitch the project you’ve been married to for the past two years. LSM is about rapid change based on validated learning. So if you’re afraid to kill your ugly baby, don’t pitch it.
• Balance - find a team with a balance of designers, developers and “marketers.” The last thing you want is to join a group where nobody can install google analytics on your landing page.

Tips for Winning

I believe the winning team will be the group of people who show the most acceleration in their pirate metrics based on the pivots they make. Each pivot should be based on validated learning. So how do you make that happen?

Once you’ve picked a product to work on and you’re ready to get started, I would suggest that you split the group into two teams: the Inside Team and the Outside Team. The main strategy is for both teams to collaborate on structuring experiments, and then run each experiment independently to accelerate the learning process. Consensus among both teams is paramount, so there are certain activities which should be done together. Namely, defining the problem, defining the solution and agreeing on each pivot.

The Inside Team is responsible for testing the viability of the online channel. They’ll be putting up landing pages and A/B testing various pricing models and value propositions. They’re going to be writing blog posts, and building out the MVP.

The Outside Team is responsible for hitting the streets, making customer contact, validating problem areas, leading solution interviews and selling the MVP face-to-face. Personally, I think this is the place where you want to be.

After each group completes a round of experiments, you should regroup, review the results, brainstorm many possible pivots, decide on which one should be implemented, and then start the experiment cycle all over again.

How Can Mentors Help?

We have some great mentors attending the event that can help you out in a few different ways. The mentors are your objective source of feedback, your fresh eyes, who can tell the forest from the trees.

They’ll let you know if they see an opportunity for you to pivot when you’re slamming your head against the desk. They’ll help you brainstorm novel ways to put yourself in front of customers, and they’ll do their best to help you structure your customer development experiments. And most importantly, they’ll motivate you, hold you accountable, and force you out of the building.

That’s it

I can’t wait to see everyone out at LSMTO. Good luck to everyone, and remember to look out for me if you want to work with the most aggressive mentor on the floor. And if you want to talk more before the event, feel free to get in touch.

Tue 17 Jan
2012

Links of the Week 5

Posted at 9:40 PM by Cameron Westland Links

Instead of posting links the minute I find them, I've started holding on to them for a week and then blasting you with them if they still hold my interested by the end of the week.

The Twelve-Factor App

If we wanted to move our app to Heroku here is how we'd have to design it!

Evaluating alternative Decorator implementations in Ruby

Decorators, and presenters, and patterns! Oh, my!

Media queries and multiple columns

A cool way to use @media queries to create dynamic columns based on the vertical height. Not applicable to our upcoming redesign though.

wbailey/command_line_reporter

We have lots of scripts which execute on the command line. This seems like a good way to get feedback from them. We currently use "puts" :)

Factory Girl 2.4.0 (Factory Girl 2.4 Goes Meta)

Our application has 6000 factory instances in it. This should speed things up a lot.

Paulasmuth/fnordmetric - GitHub

Seems like a self-hosted version of mixpanel.com with less analysis.

Exceptional Ruby: Master the art of handling failure in Ruby

Avdi has some great blog posts and this is sure to be great as well.

Android Design

Design reading for all, not just Android developers.

Wed 11 Jan
2012

Links of the Week 4

Posted at 6:49 PM by Cameron Westland Links

Instead of posting links the minute I find them, I've started holding on to them for a week and then blasting you with them if they still hold my interested by the end of the week.

• flyerhzm/switch_user
• pillowfactory/csv-mapper
• RSpec Best practices
• #314 Pretty URLs with FriendlyId
• #315 Rollout and Degrade
• Git In The Trenches
• Developing a RubyGem using Bundler
• Rails’ Hash#reverse_merge

Tue 27 Dec
2011

Resourcing Pair Programmers in an Agile Team

Posted at 2:20 PM by Max Cameron Startup 101

Everyone knows that practicing pair programming and agile development are the best ways to produce high quality software as fast as possible. But setting these pairs up is a lot harder than it looks. Here’s how we do it. How can we improve?

The Challenge

Resourcing pairs in an agile shop is difficult for a lot of reasons. One of the big challenges is that they have to constantly change. While one of the big objectives of pairing is to reduce developer blind spots, the same thing can also happen if you pair the same developers together for too long.

To further complicate matters, not everyone starts the day with a clean slate. They might have started a story yesterday and not finished it, or they might be leaving for an hour to go to the doctor’s office. The big point is that not everyone has the same amount of hours to devote to writing code.

Every developer has areas of expertise - and every developer has areas where they’re a novice. One of the biggest opportunities pairing brings to our team is to have these areas of specialization transfer to other developers. And unfamiliarity increases the quality of the pair because the expert is forced to articulate the challenge in a simple way to the novice.

In our experience, the key to resourcing pairs is to match people based on expertise and availability. We don’t have the perfect approach to resourcing, but we wanted to share what we’ve been doing lately in hopes of learning from you.

Our Approach

Every morning we meet for our day-planning meeting. It runs from 9:15am to 10:00am. The first order of business is to review the work each person completed yesterday, and review the work they started but didn’t finish. This step is repeated for each team member. Based on the commitments they have, we count the hours they have available for writing code, and we write it on the whiteboard.

The next thing we do is open Pivotal Tracker. As a team, we review each user story that was completed yesterday, as well as each story that was started but not finished. Then, we begin selecting new stories from the current iteration - which have already been prioritized by our product manager and customer support agents.

After we select each story (starting with the ones that weren’t completed yesterday), we create a pair based on their available hours, and their level of familiarity with the particular story. We’re looking for people who have about the same amount of productive time available. We also keep an eye out for an expert and a novice. We keep assigning stories until all the pairs have a full plate.

Next, we sequence the stories - discussing any dependencies or scheduling conflicts, and discuss any risks associated with other commitments. Once that’s done, we open up the floor to questions, and when those are done it’s time for announcements, which can be professional or personal. And we generally save a few minutes to look at one of Dave’s awesome youtube favourites.

If you like lists, I’ve included one below so you can review it and put it use. If you have an idea on how we can improve the way we resource pairs, please find me on twitter or write something more detailed on hacker news.

The Big Bang Morning Meeting:

• Each person states yesterday’s accomplishments
• Each person states work that was started but not completed
• The number of available hours are recorded on the whiteboard
• Repeat for all developers
• Open Pivotal Tracker
• Review work finished yesterday
• Review work started but not completed
• Select a story from the top of the current iteration (including stories started but not finished)
• Assign the pair based on available hours and Expert/Novice
• Sequence the activities to account for prior commitments
• Assess any risks
• Questions and Announcements
• Get to work!

Tue 13 Dec
2011

The Path to Being a Programmer

Posted at 11:18 AM by Joonha Shin Startup 101

Most people don’t know what their career will be when they are in high school, and I was no different. Now that I’m a young adult, I’m ready to graduate from university and kick-start my career as a professional programmer next May.

Naive Thoughts

Before I started university, I knew nothing about computer programming. I used computers to check emails, chat on MSN, download MP3 files, create PowerPoint slides and write Word docs. Somehow that seemed enough to choose ‘Computer Engineering’ as my degree at University of Waterloo. I already liked using computers, so I figured I wouldn’t mind learning more about how they work.

I did a lot of programming in my first year. C# was the first programming language I ever learned, and at that time I thought programming was fun. It reminded me of playing with LEGO when I was a kid. It was challenging to bend the the computer to my will, and the joy I felt when my code actually did what I wanted was amazing.

I remember coding in my residence with two roommates who were taking the same courses as me. Sometimes we worked together because none of us had any programming experience before coming to university. It was difficult enough to get my code to work while receiving help, and it felt almost impossible while working alone.

I wasn’t good at asking for help when I needed it, and I needed it often, and by the start of my second year I became completely overwhelmed. Programming wasn’t something I looked forward to, and soon became just a school project I had to complete by a deadline I could never seem to meet. It felt like ‘professional programmer’ was not a viable career option.

Breaking Point

When I got my third co-op job as an automated test developer, I programmed alone most of the time. My job was to tweak and maintain an internal tool built on VBScript that was only going to be used by me and my supervisor. I found it really boring, and it showed. My boss caught me dosing off on my desk, and it ended any chance I had at having a pleasant work term for the remainder of my three months. I was ready to leave the world of programming for good.

I put school on hold and decided to take a year off to closely analyze what kind of person I was and what kind of career I wanted. I was told by family and friends that travelling is good for soul searching so I even planned on going to Japan to teach English for a year. I almost did it, but in the end I got cold feet. I was afraid of being away from school too long and not being able to adjust to being a student again.

Epiphany

I switched out of Computer Engineering hoping for the best, but no one told me that even in Management Engineering, I would be doing some kind of programming. It turns out learning about Information Technologies and Management of Technology involves programming in HTML, PHP, MySQL, and C#. Programming for the first time in close to a year brought feelings I couldn’t understand. I knew I wasn’t supposed to like it, but I found myself wanting to give it another try.

That term, out of all the courses that I was taking in Management Engineering, the ones that required programming were my favourite. I now had a different attitude while programming - I enjoyed it. These projects had less restrictions and allowed me to work at my natural pace. The mandate of Management Engineering is not to teach students how to program, but rather to teach them just enough through application in order to understand the bigger picture of software design, telecommunications, and other issues associated with the use of information technologies. I could not leave the programming world - but I didn’t want to anymore.

Now

Two years later, I somehow ended up at Big Bang Technology as a Junior Web Developer. I still consider myself pretty bad at what I do, but it feels right at the moment, and I’m sticking with it until my next revelation.

You can find me @joonhashin on Twitter. I'd love to hear your story on how you ended up choosing your professional career.

Wed 16 Nov
2011

Selling Lean: The “Two Promises” Approach to Sales

Posted at 4:47 PM by Max Cameron Customer Development

In this post, I’ll show you a Lean way to test a product and get paying customers over a weekend.

This approach is tailored to the attitudes and behaviours of visionary customers, not the typical customers who “need to see it live” before they sign up. These are the customers who are truly excited about what you’re building, and they’re willing to sacrifice a full feature set for that one magic button that solves a problem they care about.

I challenge every one of the Dooo.sh/it participants to run an experiment: Get at least fifty paying customers before you write your first line of code or put up your first splash page. A lot of people think this is impossible and never come back. But it’s not, and it’s a great way to separate the entrepreneurs who believe in Lean from those who don’t.

You can also read about some other lessons I learned while putting this tactic into action.

I said before that this activity is an experiment, and therefore we must have concrete criteria for success. I usually recommend seeking 80% validation from a sample size of 40 customers.

The Scenario

Approach a Customer

Rule number one is the customers must not be friends or family. These people are great, but give you skewed data because they want to see you succeed. Real customers only care about your product, and that’s the only thing that matters.

Problem Interview participants, referrals, cold-calls, and drop-ins are ideal candidates for this experiment, and it really highlights the need to track who you’ve talked to before so you can contact them when ready.

Prepare the Shock

I always recommend that you start with the bad news - that you’re going to be asking for money. Remove the anxiety the customer feels by getting it out in the open and moving right along. I like to say something along these lines:

“We’re a serious company building a serious product - but we need serious customers to make this whole thing work. So at the end of this interview, and i’m going to ask you for twenty dollars. It’s the only way I know for you to prove I’m doing the right thing. Now let’s get started.”

Demonstrate the MVP

I like to start by describing the problem, walking the customer through a set of wireframes, giving them a data sheet about the deal, and most importantly - telling a compelling story the whole time. Stories build trust and empathy, and they help you demonstrate a deep understanding of the problem at hand.

When the demonstration is over, it’s time to start thinking about the Close. Remember the twenty bucks you mentioned before the demo? Yup, it’s coming back.

Typically I’ll say something like, “I’m going to be honest with you - 20 dollars might not seem like a lot to you, but it’s a big deal for me. And if I’m going to ask you to go out on a limb for this product, the least I can do is make you two promises in return.”

Two Promises

Promise 1: The Date

Even without a piece of software, I’m not afraid to say “I’ll deliver you a piece of working, beautiful software by [Insert launch date here]. And if it isn’t done, I’ll send your money back with an explanation of why.”

I also like to use humour to my advantage and offer up my parents’ home address, my cell phone number, and the name of my bank manager to establish that I’m a local guy and I’m not going anywhere.

Promise 2: The Discount

Then to make the deal sweeter, I say something like, “Because you’re a visionary customer, because you obviously get what I’m trying to do here, I’ll give you $200 of credit to use with my product when it launches.” Notice the subtle compliments we’re giving the customer at this point. These visionary customers have an opportunity to “join the cause,” so to speak. And having a targeted position will always present a more compelling pitch.

Close the Deal

And finally, I’ll say, “I’d love to do business with you today,” maintain eye contact, and let the air hang dry. I try to avoid asking questions like, “Can I sign you up?” or “Would you like to go ahead with this?” and prefer using affirmative statements. As you sign up more visionary customers, the goal is to gradually reduce this discount until it is equal to a one-month free trial.

If you’re lucky enough to sell, there are three critical follow ups that need to happen. First, ask for a referral. This will most likely be your next paying customer. Then, I always recommend that you get a picture, with your customer, holding the twenty dollar bill. You have no idea how much this will motivate your technical co-founder. After that, give them the data sheet outlining the deal with the two promises, and record the customer’s info in your CRM tool.

Next Steps

If you don’t hit your goal of 80% validation for your sample group, you have the following options:

• Keep your solution the same, and pivot the type of customer you’re talking to.
• Keep your market the same, and pivot your feature set.
• Pick a new problem and start again.

Here are some topics that haven’t been talked about in this post:

• Lean solution validation for free products (article coming soon)
• Lean soluton validation for enterprise sales

Hope you found this useful. Find me on twitter if you’d like to talk more, or join the conversation on hacker news. But instead of doing that, you should get out of the building and sell something.

Thu 27 Oct
2011

An experiment in Geolocation

Posted at 3:29 PM by Adam Doeler Programming, Technology

I’ve been experimenting with web-based Geolocation technologies in a small proof of concept Rails application. The application itself is pretty vanilla: I wanted to build something that shows me where I am right now, and where some determined locations are at a fixed position. The idea being that I could see how far away I am from my favourite donut shops.

The biggest challenge in designing a system like this is deciding how to track Geolocation information in the application. I already know there are many server-side IP-based Geolocation patterns. But HTML5 offers a Geolocation api, so I wanted to look into some of the patterns that are just emerging, so I could choose the best way to track location data.

Round Pegs, Round Holes

If you’re a real software engineer, you probably know interesting problems have many possible solutions - the best of which will depend on what you’re actually trying to accomplish. Based on what I wanted the app to do, I started to research both server-side and client-side solutions, with the intent of really understanding why to use one over the other.

Below I will explain some of the realized benefits and disadvantages of each.

Server-Side IP-Based Geolocation

Benefits:
– lives on the server, so signal strength isn’t a factor.
– does not require end-user permission, so your UX can be slightly simpler.

Disadvantages:
– usually relies on existing geo databases; which could become stale
– accuracy suffers - you can only locate people at the city level.

Where would I use this:
– Auto-selection of country specific information; language, currencies, etc.

Client-Side HTML5 Geolocation

Benefits:
– high accuracy (street level) - You can locate objects within a few metres of their actual location.
– requires end-user permission - People are fickle.

Disadvantages:
– browser compatibility (HTML5) - if you care about that sort of thing.
– depends on signal strength - EDGE may not cut it.

Where would I use this:
– Real-time indicator of users location, nearby points of interest, etc.

After gathering this research, I realized my application serves two primary functions: One to track a visitor’s current, ever-changing coordinates. The other to locate a destination based on fixed coordinates. I am using a combination of these technologies, and also a hybrid model which interfaces the client-side information back into the Rails application.

If you are interested in reading the source code of this proof of concept, take a peek at my Github repository.

Wed 26 Oct
2011

Update: Working for a Startup

Posted at 9:24 AM by Joonha Shin Startup 101

My name is Joonha Shin, a co-op student from University of Waterloo, and I’ve been working at Big Bang Technology for just under two months.

“So how’s your work going so far?”

It’s question that I get asked often. Whether it’s close friends from high school or fellow classmates also working in Toronto, they want to know what kind of work I do and what the working environment is like. I’ve also found that people are more curious about my work now that I’m working for a startup than when I used to work for big, international companies.

It’s almost like they also want to try working for a startup, but don’t want to take the leap of faith and try it for themselves. Maybe they would rather hear my stories and experience them vicariously, and that’s good enough for them. They ask me questions like, “So what’s the work place like?”, “What do you guys do?”, “How many people are in your company?”

I wanted to write this blog post so that people can get a feel for a life at Big Bang HQ, without actually working here.

First Day to First Two Weeks

On my first day at Big Bang Technology, the first thing I noticed was how the place looked: wooden floors, white brick walls, high ceilings, comfy couches, paintings, plants and six 27” Apple monitors. I felt a blend of both modern and classic design; I liked it.

When I first started in September, there were eight of us including myself. Soon, that number will go up to nine. For the first two weeks, I was floating around, pairing with as many people as possible. I got exposure to our development environment, the typical work flow, and how we make money. It took a while to get my feet on the ground, but after the first two weeks I started contributing a lot more.

Development Environment

One thing that’s very different here is that development is almost always done in pairs. The only time this isn’t true is if we are doing simple chores or research. Whether we are implementing new features or resolving a complex bug, we are always working together. The only time I work alone is when I’m writing blog posts or doing some quick admin work.

Even if it’s not strictly development, it’s not uncommon to see two people sitting side by side at a desk and working together. This is easy to do since we don’t have cubicles here. Sometimes, we take the concept of pairing a bit too far, like while making coffee or playing Deus Ex: Human Revolution (as well as Dark Souls) during lunch or after work hours.

To be fair, pairing isn’t always great. I’m not the world’s greatest developer yet, so when I’m pairing, I spend most of my time watching and trying to learn, rather than giving useful feedback. Sometimes it can feel like I don’t have as much input - and sometimes I feel a little useless. No one makes me feel that way though - that’s just me.

What’s Next?

One of my my biggest goals during my co-op term here is to improve my programming skills. Not too long ago, Cameron asked if I wanted to pair with him after work to do some Code Kata; I gladly accepted his offer. And although becoming a master programmer is big goal for me, having great experiences and great stories to tell is just as important.

If you’re a co-op student and you’re curious about my story, you can find me on Twitter and ask me anything you’d like.

Wed 28 Sep
2011

Why I Chose a Startup

Posted at 3:16 PM by Joonha Shin Startup 101

My name is Joonha Shin, a co-op student from University of Waterloo, and I chose to work at a startup. Here’s why.

Backstory

In January 2011, I tried starting a company with my classmate. Our university allowed us to do this as a co-op term, so it was a chance for us to do something risky but still receive some kind of a reward in the end. We had just four months to build something, then make it cool.

Over the next four months, we built a prototype that was still far from production. And even though we were learning a lot, we ran out of time and decided to put our project on hold. Our new plan was to graduate, find work, then bootstrap our company on the side.

I still had one more co-op term to complete before our graduation. I really wanted to work for a startup; someone else’s startup. I wanted to experience first-hand what to do, and what not to do when growing and managing a startup. After about seven interviews, I accepted an offer from Big Bang Technology for my final work term.

One Last Chance

Choosing the right place to work is not an easy task. There are so many options available and so many factors to consider. I knew I wanted to work for a startup, but I wasn’t sure what kind of startup I wanted to work for. I decided to figure it out as I went along.

I only applied to startups or small-sized companies. I saw my friends interviewing with Facebook, Apple, Microsoft, Deloitte, and so on. Those are all great companies, don’t get me wrong, but they weren’t what I was looking for. I’ve worked for Siemens, Research In Motion, and CGI Group; all very big companies. I experienced about two years worth of the corporate scene and I wanted something different. I was craving for a smaller, fast-moving, young group of friendly and enthusiastic people. I only got interviews with companies none of my friends heard of. Big Bang Technology was one of them.

The Result

By the time I met Max and Cameron, I already had about five interviews under my belt, and they were starting to become a routine: listen to them talk about themselves for ten minutes, then answer questions regarding my resume, then answer few programming questions. Big Bang was different. The two had made a list on the whiteboard. They were conversation topics: some were about them and others were about me. They asked me to pick five topics and that would be the interview. I got caught off guard. When the interview was over, I realized they made an impression on me. They weren’t like others, they were memorable.

Even before the offers came, I was already leaning towards Big Bang Technology. And if there were more than just blogs on their website, I would have made my decision a lot quicker.

Each time a co-op term ended, I never felt satisfied with I had done and I knew that there was something better out there, waiting for me to try it. But I’m happy to say after six co-op terms, I’ve finally found a work place that I’m content with.

To my fellow co-op students, my advice to you is this: Don’t give up and don’t settle.

Wed 28 Sep
2011

One Year of LeanCoffeeTO

Posted at 12:25 PM by Max Cameron Community

This week marks the one year anniversary of LeanCoffeeTO, a meetup group that we’re proud to belong to. I’ve written about why I think LeanCoffeeTO is a rare and valuable community resource, so we were happy to host one of the five consecutive sessions being held this week throughout the city.

The first two sessions were held at MyCityLives and The Working Group. We focused on a retrospective approach, where we looked to the past, remembered how the group got off the ground and talked about some of the amazing things that happened as a result.

We wanted our session to move the conversation forward, so instead of continuing that trend, we invited the attendees to jot down experiments that we could run in the coming year based on the conversations that have already happened.

Here are the trends and experiments we discovered:

Channel Experiments:

• Create a LCTO website outside of meetup.com
• Promote and work closer with the “splinter groups” that are emerging: Dooo.sh/it, ECSA, etc.
• Live stream each session to increase our accessiblity and reach
• Create a Chapter Kit to help other LeanCoffee groups to get started quickly and learn from our mistakes
• Integrate some sort of Q&A into the site to promote more dialogue between members

Special Event Experiments:

• Host a full-day LeanCoffeeTO conference
• Have an evening meetup once a month, IE LeanCocktails
• LeanCoffeeTO Bootcamp - a four session intensive workshop to onboard new LCTO members as quickly as possible
• Mentorship and Residence programs - facilitate residence programs between startups to socialize best practices

Activity Experiments:

• Pitch Day was very popular. In this experiment we’d critique member pitches before getting in front of actual investors (There was even talk of inviting investors to attend)
• Elevator Pitch practice - Pair up and give another member your elevator pitch, and have the listener repeat what they remember to see what parts of our pitches need improvement.
• Run Customer Development experiments at a LCTO meetup
• Lead Customer Interviews during a session to improve that skill

Format Experiments:

• Formalize and publicize a process for members without office space to facilitate sessions
• Follow the development of a specific startup over the course of two months
• There were a number of suggestions to bring in Subject Matter Experts and business leaders in for a speaker series

Wrapping Up

I’m not here to critique or endorse any of the experiments that came up today. However I do believe that LCTO could benefit from a lot of these ideas. I also think we can set ourselves up for success if we keep these ideas in mind:

• Run the smallest version of the experiment instead of attempting to pull off major initiatives
• Structure the experiments so they can be run no matter who shows up for a specific LCTO
• Allow pain to drive which experiments we run, instead of ambition
• Ensure the governance of the group continues to be decentralized

Looking forward to seeing you tomorrow at Jet Cooper, and judging by the package they just sent us, it should be a good one.

Wed 21 Sep
2011

Your Employees’ Personal Goals Should Matter to You

Posted at 10:44 AM by Liza Mattimore Startup 101

Understanding your team's future goals makes your business better.

Many companies do business-specific goal planning with employees to determine how to get the most out of them, and ensure they are working hard towards the company’s goals. And we do that too. But our personal goal planning is equally, if not more, important. Personal goal planning is separate from the business itself, and instead focuses on the employees and their lives holistically. And while it may seem like a “nice to have” and not a “must have,” for us it is all about championing our staff, and their goals, to ensure our company and its staff are aligned. We have committed to personal goal planning with our employees because we think it is a worthwhile experiment. After all, we do spend most of our waking life as adults, at work.

A few months back, when we were a smaller team, we did a group workshop in personal goal planning. After the workshop, we created a book with a page devoted to each employee’s personal goals. Not only does this help us keep each other accountable, we also like to share it with prospective employees and important office guests.

It was a great experience during the early growth phase of the company. We all learned a little about one another, and about how to be personally mindful of our aspirations. But we knew it would be difficult to continue workshops like that one as our team grew beyond 5 or 6 people. As we continue to grow we want all of our new team members to be able to participate in the experiment.

One of my personal goals, which came out of our goal planning workshop, is to someday be an authority on company cultural development and management. I could not think of a better project for myself personally or professionally than to lead the goal planning workshops for the newest members of our team.

Over the course of the next few months as our newest employees go through the goal planning process with me, I will be blogging about what it’s like to lead this workshop. Since I am totally new to the world of goal workshop facilitation, it will be as much a learning experience for me as it will be for “The Daves” (our newest gang members). Hopefully this will give other small businesses or start-ups some ideas about what worked well for us and what we learned along the way.

Fri 16 Sep
2011

How to Poach a Startup Employee

Posted at 2:16 PM by Max Cameron Startup 101

It’s easy: Walk down the street to the next startup, find someone awesome, and offer them something better than they already have.

If you’ve ever worked in a startup, you know how close the bond can be between the members of a small team. So when someone quits, it’s easy to get bent out of shape. But lately, I’ve seen situations like this get a little too personal. Here’s the bottom line: business is business. And if you lose an employee, it’s nobody’s fault but your own.

Let me just say that employees are people too, and they should be able to work wherever they want to without justifying it to anyone but themselves (and perhaps their loved ones). They also deserve the best job they can find. In my opinion, job one for any business owner should be hiring the best people around. Job two should be making sure they laugh recruiters out of the room.

Eight ways we make recruiters hate their jobs:

Daily Feedback: We’ve written in detail about daily feedback and our day-planning methodology. It keeps the team engaged, and promotes a horizontal management structure. When everyone holds everyone else accountable, we help each other learn.

No Overtime: Zero, zip, zilch. We’ve also written about that.

Developer Development: Our unique skills workshop isn’t just for developers. We benchmark everyone’s skills, set goals, and structure experiments to help our team get better at their craft.

Full Benefits: A great benefits package, 100% covered by us. Our team has bigger things to worry about than dentists and eye-glasses. If you’re a startup employee and you don’t have them, we’ve even written a series of blog posts to help your bosses get started.

An Awesome Office: We’ve designed an office space that no one wants to leave. Then we force them to go home at five. Pretty awesome, eh?

Continuing Education: We have a dedicated education budget (still underutilized, tsk tsk) that our team can use to buy books, attend events, and enroll in classes.

A Healthful Atmosphere: We encourage everyone at Big Bang to lead a healthy lifestyle. That’s why we provide unlimited free yoga at Downward Dog, and stock the kitchen with tons of free healthy snacks.

Team Lunch: We take our whole team out for lunch once a week. The team loves it, and we’ll keep doing it until the only available option is getting caterers to come into the office. We also make a point of eating together at the same time whenever possible.

Retrospectives: Our weekly retrospectives deserve their own blog post. We take an hour every week to discuss what went well, and what didn’t. Then we structure experiments to fix what went poorly and augment what worked nicely. So far, we’ve implemented about 15 experiments. I’d say about five of them have been successful.

Here’s the Deal

As business owners, we shouldn’t wait till a team-member quits then burn valuable bridges. Instead, we should always strive to design a work experience that delights whoever is brave enough to work with us.

So yes, it hurts when someone leaves your team. But business owners need to get over it, step up their game, and take away every reason to leave.

Love it? Hate it? Find me on twitter or jump on hackernews and let me know.

Tue 06 Sep
2011

Experiments in Early-Stage Customer Acquisition (ESCA)

Posted at 8:01 PM by Max Cameron Customer Development, Startup 101

Customer Development comes along and tells us, “Go get your customers before you have a product.” OK, I get the strategy - I bought into Customer Development a long time ago. But when it comes down to the tactics, and you’re staring down your mailchimp list, you know it’s harder than it looks. You know it is.

Why is it Hard?

Mostly because I made a deal with my co-founder that I’d have a few thousand (ahem, five thousand) signups by the time we released our beta this fall. As of right now we have one-hundred and twenty-six.

If you’re in a really early stage, like we are with Chill.ly, we’re still trying to validate the problem we want to solve, our value proposition, and the channels we want to use, to reach a certain segment of customers. That’s a lot of validating to do my friends, a lot of validating.

What I’ve Tried So Far

We have a goal set that says if this project will be successful, we should have five thousand signups by the time the leaves are red. We put up a landing page that describes our problem and urges our visitors to sign up and save some money. Then my task shifted into, “drive some traffic to the site.”

Here’s how I’ve been trying to do it so far:

• Friends and family, social networks: Got us to about 50.
• Forums: Forums are skeevy and I’d prefer not to troll them.
• Betali.st - Easy approval, we received about 25 signups that day.
• Hackernews - Asked the community to take a look at our landing page and leave feedback. Resulted in about 10 signups. Come on HN that’s weak.
• Google/FB Ads - They work, but not a home run. We’re looking at a CAC of about $1.50, and that’s only for a beta signup.

A note on blogs: Blogs are tough. Any blog with a decent readership is reluctant to write about a product that hasn’t launched yet. Mostly because they have a fear of publishing fluff/pr pieces. I understand that. As a result, getting written about on good blogs is a long sales cycle.

What I Want to Accomplish

I have a few coals in the fire, and I’m going to crack this blog fiasco. We’re also going to wrap up our first advertising test and get a benchmark for our CAC. That will give some data to measure against when we make the changes to the landing page we’ve been planning out.

What am I missing here? Find me on twitter or fill me in on hacker news.

Tue 23 Aug
2011

Ugly Babies and Customer Development

Posted at 5:17 PM by Max Cameron Customer Development, Startup 101

Here’s my point: Products are not babies - you shouldn’t feel bad about abandoning them if they’re ugly.

The Problem with Problem Interviews

Customer Development teaches us to validate our assumptions before we build our products so we don’t waste time and money building something that nobody wants to buy.

The problem is that many people have already spent a lot of time and money building products based on assumptions that haven’t been validated before deciding to incorporate customer development. The more blood, sweat and tears we pour into a product, the more likely we are to throw on the rose coloured glasses, and pretend our ugly baby is the cutest kid on the block.

Now, because we think our ugly baby is actually beautiful, we pay lip service to critical Customer Development initiatives like the problem interview. Instead of taking advantage of an incredibly powerful tool to uncover insight from customers, we throw up a survey and congratulate ourselves for finding “problem/solution fit.”

Too Bad It’s a Lie

We play tricks on ourselves because we desperately want to believe we’ve done enough due diligence. Here’s how:

• We turn a problem interview into a solution interview.
• We rely on surveys and questionnaires which assume we know the right questions to ask.
• We ask leading questions.
• We talk to the wrong people.

None of these activities actually help us. Problem discovery is about uncovering what is unknown, not what we think is correct. What’s even worse is that many customer development advocates and evangelists promote an approach to problem discovery that I would not describe as vigorous. They basically endorse having potential customers go through a “problem checklist.”

A Better Way

At Big Bang Technology, we care about discovering the right problems, not just validating the ones we already know about. So we dive deeper into problem discovery by adhering to some design practices. We like to lead open-ended interviews where we stick to a problem domain, and freely explore all aspects of that domain with our potential customers. Because we don’t box ourselves in to defining the problems up front, we discover unexpected problems that could never have been found with a checklist.

Doing this means we spend a lot more time in the problem discovery and validation stages than a lot of other people. We also might burn through five or six (or ten) problems that aren’t worth solving before we find one that is. And we're ok with that. But what’s even more difficult is finding the humility it takes to acknowledge - or even suspect - that we won’t get it right the first time.

Thu 07 Jul
2011

Why We Don’t Work Overtime

Posted at 7:54 AM by Max Cameron Startup 101

There are no heroes at our office. When the clock strikes five, the team goes home. If they try to keep working, I tell them that the game’s over and they lost. They either put too much on their plate, got taken off-task, or were wasting time. None of those justify working past five, on a holiday, or over a weekend. The only exception we make is for the founders, and it should be obvious why that’s the case.

Yeah, Sure.

A lot of people think I’m joking when I say this, but I’m not. I would rather shut my company down than ask my team to work overtime. That might sound harsh, because many believe overtime is just part of doing business. But working overtime undermines the values of our company. And if we undermine our own values, how could I expect anyone to believe in them?

Having this conversation with clients, especially in times of crisis, can be difficult and uncomfortable. But if I’ve learned one thing starting Big Bang, it’s that I earn my money having difficult conversations.

Ouch.

A conversation like this usually results in the other party feeling overwhelmingly disappointed, if not outright angry. Harsh words are spoken, and they’re usually directed at me. And that’s understandable, because they usually have pretty good reasons to be asking for us to, “just get it done.”

Reason 1: Money

Sometimes a client is presented with an opportunity to win new business, and needs your services to accomplish that goal. I don’t blame our clients for wanting to make more money. The more money they have, the more business I can benefit from.

Reason 2: Pressure

Sometimes a client is put into a difficult situation by one of their customers, pressure that can only be alleviated by the activities we do. I genuinely feel bad when our clients have to deal with issues like this, because I wouldn’t want to be in that situation either.

So why not just do it?

The short answer is: because it erodes leadership, my team will quit, and it destroys the joy associated with the work we do. The long answer is more interesting.

The Hero Mentality

The concept of sacrifice is typically used to persuade employees to comply with working overtime. You know who makes sacrifices? Soldiers do it charging into battle. Firefighters do it running into burning buildings, and police officers do it diving in front of bullets. They make the ultimate sacrifice, and it’s a powerful idea to be associated with. The same goes for the idea of making a difference, or saving the world, or helping out the team. They’re all compliance tactics, and they’re a dangerous habit to get into.

When an employee makes a sacrifice that is dear to their heart, like spending time with family or pursuing a hobby or interest, two things happen: first, they immediately distinguish themselves from the employees who cannot (or choose not to) comply. There are now two groups of employees: The winners who stay late, and the losers who let you down. Yearly reviews just got a whole lot easier.

More importantly, the employee who stays late is then perceived as heroic in the eyes of their team members. Like the dad who worked in the coal mine for sixteen hour shifts, or the marine storming a fortress of evil-doers. Who wouldn’t want a team that would make the ultimate sacrifice for your company?

Of course, this leads to burnout, which is a well-documented and treacherous outcome. From low productivity to high levels of disengagement to costly turnover, it should be clear why burnout should be avoided at all costs. Much like accumulating technical debt, it’s easy to just “put it on the credit card,” so to speak. Unfortunately, credit cards have to be paid off, usually for more than you borrowed. (Check out Peopleware for more information).

But more damning than burnout, this leads to an environment where an employee cannot be seen as a leader without sacrificing the things they hold dear to their heart. How could I promote a loser when they’re surrounded by winners?

It might be tempting for someone to jump at the money they’ll make from their team doing the impossible and going above and beyond. I just wonder how they could justify losing the people that make their team great in the first place.

Beyond Overtime

Any employer can say they have values. Especially in a job interview when everything’s looking real peachy. But values are just words if they break down in a crisis. If I destroy our values by requesting overtime, how will my team ever make real sacrifices for our company? Constantly growing and challenging themselves to learn, being more autonomous, and becoming better people will ask far more of them than putting in an extra ten hours over the weekend.

I guess I am asking them to work overtime after all, just not on the things they consider work.

I'd really like to thank Joannou for helping me with this article. You'll be hearing more about him later. If you think I'm crazy, find me on twitter and we can talk about it. You can also participate in the discussion about this article on hackernews.

Tue 14 Jun
2011

Party Notes App

Posted at 7:16 PM by Max Cameron Startup 101

Do you remember what happened last night? Didn't think so. We're going to help you fix that with a simple iPhone app.

My eyes open. One at a time, still twitching. The second one takes longer because it's sort of stuck together. The sun's out. The last time my eyes were open the sun wasn't out. That's no good. Where am I? Yes, that's my Ultimate Warrior poster on the wall. That's good. My arms are reaching around me. Nobody's there. That's also good.

Where are my keys? And my phone? And my wallet? And my dignity?

Hopefully they're downstairs. I can't live with not knowing.

What happened last night?

We've all been there, and it's time to fix that. Stay up to date on our new app, Party Notes.

You'll be glad you did.

Thu 26 May
2011

Customer Development Meets Startup Weekend TO

Posted at 4:15 PM by Max Cameron Community

Nearly all startups fail, and although failure is often awesome, I would really like to see some successful products come out of Startup Weekend TO. I’ve become engaged in the lean startup community in Toronto, I’ve run some cool experiments, and I started a workshop for early-stage startups who are interested in customer development. I think that’s why Chris asked me to address the group, and coach throughout the weekend.

In April, a few of my cohorts and I went down to Boston and participated in Lean Startup Machine, which was a weekend much like Startup Weekend TO but exclusively geared towards customer development activities. The experiments we initiated there were extremely helpful in learning not just the theory, but the practice of a lean startup.

I’m thrilled that Chris and the other Startup Weekend organizers have agreed to incorporate customer development activities into their judging criteria. I hope to see many groups adopt these values, principles and practices, because I think it will increase the odds of Startup Weekend TO launching a successful product.

Incorporating Customer Development

• Create a Lean Canvas to clearly illustrate your business model. Create a few so you can compare them and choose the best.
• Document your hypotheses and assumptions about your product and your customers.
• Make customer and/or user contact immediately and start testing your ideas.
• Learn what to build, for who, before writing a single line of code.
• Prove that your idea is worth actual money by engaging actual customers immediately.
• Pivot different aspects of your product (radically or subtly) as you learn more about your customers and their actual needs.

Who should ignore this?

Let’s be clear: if you don’t plan on making money from your product, or having it be widely adopted, do not feel pressured to make use of these activities. Itch-scratching and programming experiments should only have to satisfy one person: you.

If you’re building a website that creates gold, or the cure to cancer, or magical bottle of beer that never, ever stays empty, do not bother with customer development: people will line up to buy your product.

Who should run with it?

If market adoption is the biggest challenge your product faces, and not your ability to build it, these techniques will assist you in molding your visionary concept into a product that people will buy. It doesn’t matter if you’re an early-stage startup that is as malleable as putty, or a product that’s already in production, you’ll be able to learn a lot by getting your hands dirty and yourself out of the building.

Non-technical co-founders should be especially happy about this new track, because they can feel free to pursue the idea they’re obsessed with, instead of being at the whim of their more technical counterparts.

Coaching During Startup Weekend

In addition to speaking, I’ll be on hand to help groups that want to practice customer development all weekend long. I’ve learned a lot during the past few months, but the most important part of my workshop is giving people a few tips, and literally throwing them out of the building.

Customer development is a game of confidence. Once you start having success, it becomes easier and more rewarding. I’m really looking forward to working with you.

If you’d like to get started on customer development before you arrive at Startup Weekend, please take a look at Ash Maurya, Eric Reis, and Steve Blank.

And if you have any questions you'd like me to answer, please ask me anytime.

Fri 20 May
2011

An Introduction to Web Sockets

Posted at 9:29 AM by Max Cameron Programming

Last night at Toronto's HTML5 Meetup, Cameron was given the opportunity to speak to about 40 members of Toronto's developer community about Web Sockets. Not only did he talk about the technical implications of the new protocol, he raised interesting questions about the design opportunities that will emerge as Web Sockets become more widely adopted. If you weren't able to make it, we hope you enjoy watching the presentation here.

Tue 03 May
2011

Zen and the Art of Crisis Management

Posted at 5:00 PM by Max Cameron Startup 101

Shit happens. It’s unavoidable. The real magic happens when and how we respond.

There are two types of people in the world: Panickers, and Zen Masters.

The Panicker becomes hysteric, and recklessly sprints toward the disaster with their head down in an attempt to solve the problem immediately using brute force. This usually turns a disaster into a catastrophe, and ultimately produces a vicious cycle of ever-increasing proportions.

The Zen Master does the exact opposite: they stop. The Panickers are shocked and panic even more. They think the Zen Master is paralyzed, but that’s not the case. The Master is cold as ice, running models in their head, trying to really grok the situation and why it happened. Time is going by, and people are still freaking out. But the Zen Master is weighing all the available options, looking at the issue from many perspectives. Then, when everyone thinks the sky is about to rain down fireballs, the Zen Master calmly decides to act in order to resolve the issue in the most efficient and permanent way possible.

How Two Chefs Respond to Crisis

It’s autumn 2004, on a crisp Saturday night at 8pm. I’m the sous-chef in a small, exclusive French restaurant in Toronto. This isn’t amateur hour here, this is the real deal. The open kitchen is tight quarters, fitting only two people. Our uniforms are clean, the mark of a professional. Every tool is in its place so we can access them instinctively. I’ve been prepping with the Chef since 2pm, and we’re pretty well set to handle the rush. This kitchen is a well-oiled machine, and there’s no room for disorganization.

We’ve had a few tables up until then, a nice little warm up for us to get loose. It should be obvious what happens next: twelve tables arrive and are seated within fifteen minutes of each other. The volume of the restaurant picks up a few notches. Glasses are being filled with nice wine, and laughter fills the room.

I’m licking my chops and getting psyched. Finally, the tickets come flying in, and I’m seriously feeling the flow. We’re calling out orders and working hand in hand to get our first round of appetizers out. We’ve sent out apps to about eight tables and everything is perfect. The plates from the first table come back, so we start sending out the mains. More tables are being seated, and we have about a fifteen minute backlog. It’s all good though, because everyone’s having a great time.

Then disaster strikes. I forget about the mashed potatoes I put on the stove to heat up for the mains we’re about to send out. It’s completely burned and I have to start over. All of a sudden, the well-oiled machine starts falling apart. The meat in the oven is going to overcook, and we’re working on plates for about six tables at a time. That means the timing for about twenty-four entrees just got put in jeopardy. This is a huge mess. The disaster compounds - we sold a lot of salad and we’ve run out of lettuce. That means more prep time. I have half a salad ready to go out.

Here’s how two chef’s I worked for at different times handled the situation:

Tim

Tim is the Panicker. He’s a shade over 6 foot 4, had blond hair, and seldom shaves his beard. Sometimes he shows up for work still wearing the chef’s uniform he left in the day before, claiming he hasn’t slept and has just returned from a wild party. When a disaster like the one I described strikes, Tim starts doing his famous tick - he starts rocking back and forth on his heels.

I hate disappointing Tim because he’s a Panicker, but I have to break the news to him, and I see that scary look in his eyes. Now he’s yelling at me while he starts rocking on his heels, back and forth, back and forth. Tim is yelling at me because of what I did wrong, and how this is going to ruin the night. “These people will NEVER come back. We are BETTER than this.” He picks up my half-plated dishes and literally throws them in the sink from four feet away. Patrons look up. I tell myself I’m quitting as soon as the night’s over. He shoves me out of the way, grabs a saucepan, and starts a new batch of mashed potatoes himself. I’m humiliated, and I wait for him to summon me back to my station.

Shawn

Shawn is the Zen Master. He’s one of the nicest guys I’ve ever met. He has a daughter and a wife. He loves comic books and science fiction. He’s always experimenting in the kitchen and constantly trying to improve his technique. I’m not afraid to tell Shawn about the disaster, in fact I tell him a few minutes before I tell Tim (I was trying a last minute fix even though I knew it was pointless) because I trust Shawn. He trusts me too.

When I tell Shawn what happened, the guy actually smiles and calmly stops the entire system. I can’t believe it. “Shawn, these people are going to walk out.” “It’s okay man,” he says, “Screw em. They might freak out, but we have to fix this situation, and us freaking out isn’t going to get us there.” He stands directly in front of me, without rocking his heels, and looks me dead in the eye. “Calm down now Max, right now, and focus.” I can’t hear the noise of the room any more. I can feel my mind working again.

My heart returns into my chest. Shawn’s not freaking out. No dishes have been broken, and no feelings have been hurt. But we still have a problem and the next part is key. “What is the next step you need to do to get this thing moving again? Talk it out with me.” “Well,” I reply, “I need to restock on lettuce, then start the mash on table 4 again, and then I should be able to get back into it if you can hold off on the meat for about ten minutes.”

“Okay man, let’s do it, we’re in this together.”

42

Crisis is unavoidable and out of our control. What is under our control is how we deal with crisis when it strikes.

The next time we release buggy code into production, or seriously mismanage a client’s expectation, or realize we might miss payroll, we should try to resist the urge to react immediately. We should instead do the following:

• Observe the crisis and take in as much information as possible.
• Orient yourself by understanding the root cause of the crisis and brainstorm all the possible solutions.
• From all the possible solutions, decide on the one that will resolve your crisis in the fastest and most efficient way possible.
• Act.

You can read more about the OODA loop if you want to.

And most importantly, we should remember that it is in times of crisis that we absolutely depend on being cold, calculating, and at peace with our purpose in life.

Thu 21 Apr
2011

What to do when your DNS fails

Posted at 1:46 PM by Adam Doeler Programming, Technology

On the morning of April 19th, our phones started ringing, and our email clients started filling up quick. Our software, Woople, was suddenly inaccessible to a large majority of our users. My initial reaction was that the application servers had come crashing down. Woople’s usage has been growing fairly quickly in the past couple weeks. New Relic RPM showed us lower than normal usage, but our cluster was still responding as expected.

It was quickly discovered that Media Temple was having a critical DNS outage. Meaning domains & email using Media Temple’s domain name service disappeared. If it isn’t clear yet, we were using Media Temple’s provided name service. Woople uses subdomains for individual accounts on the system. What’s that sound you ask? It’s shit hitting the fan.

We immediately setup a FREE plan on Zerigo, and updated our name servers at the domain registrar. Almost instantly the query counter on Zerigo started to increase. Users were regaining access to woople. (Rest assured, we’ve since upgraded to a plan that can handle quite a bit more than what the FREE offering had.) This solution worked so well for us because our original name servers were not responding. The natural next step for any domain routing system is a hop to the next available name server.

Our next steps are to completely decommission use of Media Temple’s name servers. To be fair, they have been fine for the past two years, but we need something we can trust. A specialized service from Zerigo fits that request now. Taking this even further, setting up a master / slave relationship to another provider is also a viable option, and I’ve been looking at Route 53 and the Dynect platform for this.

DNS redundancy comes cheap with the help of specialized service offerings available now, and it is often overlooked until it bites you in the ass.

Thu 07 Apr
2011

We’re looking for a Desktop Class Web Application Design Engineer

Posted at 11:19 AM by Cameron Westland Programming

Designer/Engineer is a hybrid role that combines interaction design practices with disciplined engineering activities. Desktop Class Web Applications are Web Apps that feel like they belong on an iPad.

About You

• You understand the basics of Ruby on Rails best practices (You might have completed something like codeschool.com Rails Best Practices at a minimum).
• You've written some ActionScript or JavaScript code from scratch and you've become frustrated because it gets messy fast.
• You know how to write a fairly complex SQL query.
• You check your code into git and you understand the value of social coding on GitHub.
• You've probably got a few open source projects or experiments up there.
• You pair program with buddies or have sat down and talked about hard problems with them before.
• You write unit tests in any language you can. You might still be frustrated because you haven't gotten comfortable writing them first yet.

Desktop Class

There is a spectrum of web-based software that has emerged in the last ten years. On the one side you've got CNN.com and on the other you have Gmail. In between is a gradient of richness which on the left is fairly static, and on the right is the desktop class. iPhoto, iTunes, Microsoft Word are some examples of desktop class applications. We believe that the Desktop Class Web Application is the best paradigm for Personal-Computer-based Web Applications. By focusing our expertise in this paradigm we are exposed to exciting challenges and unsolved problems. The added complexity of the Desktop Class Web Application needs a different type of professional: one who is equipped with both Engineering and Design skills.

About Us

Big Bang Technology was created with a founding premise that says the infrastructure enhancements available on the internet will create a digital big bang of progress and development that will completely reshape the face of computing. We think we're just at the beginning and things are only going to get more exciting. We're building our company around to be around for a long time. We’re going to take advantage of this wave. Our current focus is on Desktop Class Web Applications. We use cloud computing technologies and rapid development tools to make this happen. The goal isn't to be puritans about the technologies we choose, but to choose tools which will help us learn the most as fast as possible.

We're not interested in Rock Stars who can pull miracles out of nowhere and score the winning touchdown. We're looking for team players who love work when they're at work, and love something else when they're at home.

If this sounds interesting, you should contact us because we're probably looking for you, and you're probably looking for us.

Contact: cameron@bigbangtechnology.com or ask me questions on twitter: @camwest

Fri 01 Apr
2011

The Secret Life of Big Bang Technology Inc

Posted at 2:09 PM by Max Cameron

A lot of people don't know what we do for a living, and think we can somehow keep the office open by pulling absolutely amazing April fools jokes. But we actually do work hard, and this week has been especially exciting. Read on to reveal the secret life of Big Bang Technology Inc.

We Have Jobs. Promise!

Not a lot of people know that we build a video-based eLearning platform for the enterprise, but we do, and it's called Woople. A lot of eLearning software stinks, and we're having a blast bringing eLearning into modernity. We did a Woople case study a month or two ago at LeanCoffeeTO about how we got into it, and how the partnership business model works.

We're lucky enough to have some pretty large clients using Woople. It might surprise you to know that every single Allstate agent in the United States uses Woople for sales and customer service training. Nissan is also using Woople to provide education for the launch of the Nissan Leaf. It's a tremendous amount of fun, and this week hasn't been an exception.

SAML SSO

The first thing that's going into production is a SAML2 SSO implementation we've been cooking up with Allstate. It's been fun, as I'm sure you can imagine. I bet my dad is laughing right now.

Data Feed

We've also been working on importing a massive data feed that will create tens of thousands of users and accounts six days out of seven so people have something to SSO into. This has been a major challenge because getting data out of an enterprise is like smuggling rare birds out of Guatemala. You drop 'em in a demilitarized zone out of the firewall and pick 'em up quick.

Certification Features

We're also releasing a massive set of features where users will complete essential and a selection of elective courses to stay on track and be considered "certified." It involves a nifty points system where the elective courses are worth points and you need to accumulate a certain amount of points per month and per year. The Woople certifications feature is being rolled out hand-in-hand with live event training, and is basically a way to integrate Woople into a significant enterprise-wide education effort.

Assessments

It's hard to believe we've been building out an eLearning platform for almost two years now that hasn't had a way to assess learners, but that came into scope for certifications. So we built a bare-bones multiple choice assessment system and it has this really cool feature that displays a custom video playlist based on which assessment questions you answered incorrectly.

Conclusion

It's been a big week, and the best is yet to come. Beta tests with a small group of about 500 users will follow with the full release on the 11th.

Oh, and we still found time to pull a sweet April Fools joke.

Wish us luck!

Fri 01 Apr
2011

Big Bang Technology Inc. Announces Acquisition

Posted at 7:59 AM by Max Cameron Startup 101

We're really proud to announce our first acquisition ever. We hope to add more companies to our portfolio as soon as possible.

UPDATE: http://www.jetcooper.com/blog/deal-falls-apart/ APRIL FOOLS!

TORONTO, Canada — April 1, 2011 — Big Bang Technology Inc., the software design and development firm, today announced that it has acquired Jet Coooper, a two-year old digital agency from the city of Toronto. The Jet Coooper co-founders Satish Kanwar and Verne Ho are best known for their award-winning creative digital services and their internal product development strategy. Ho will enter as the newly-appointed Creative Director, and Kanwar will lead business development. Additional assets included in the acquisition include the social note-taking application Rocketr, along with its creators Jen Fong-Adwent and resident Futurist Andrew Peek.

Read the entire press release and take a moment to congratulate them on their blog.

Mon 14 Mar
2011

The Critical Path for Two-Sided Products

Posted at 9:11 PM by Max Cameron Startup 101

As most of you probably don't know, Retrievr is an idea for a service that fosters relationships between artisanal coffee shops and their customers by combining a social check-in service with a simple feedback mechanism. We came up with it when we attended Lean Startup Machine a few weeks ago.

I think the Retrievr story is a worthwhile case study because it illustrates an interesting and unanticipated problem: when you build a two-sided product, you can't put the cart before the horse. We focused our efforts on the coffee shop owners first because they were the paying customers in our model. We had early success and even signed up paying customers using wireframes.

The coffee drinkers were supposed to be altruistically motivated to leave feedback, and if that was the case a wonderful loop would ensue. But now we're learning that coffee drinkers have entirely different attitudes towards feedback. In an ironic twist, they consistently validate our hypotheses that customers want to provide feedback and go out of their way to help their favourite coffee shops. But they thoroughly reject our proposed solution. And so the lynchpin that's holding both sides of the two-sided system together seems to be evaporating.

We made a crucial mistake: we didn't validate the driving side of the system first (giving feedback). Instead we focused on the paying customer (paying for analytics). Even worse, we accepted payments based on data we couldn't prove we could provide. We should have focused on the coffee drinker first, even though they wouldn't be the paying customers. Our challenge would then be to create value by integrating the coffee shop into whatever that looks like.

So, if Retrievr is going to continue, it will require a very severe pivot - definitely severe enough to send back the money we've collected so far. There might even be more promising products for us to run through the cycle.

Let me know what you think on twitter.

Fri 04 Mar
2011

Introducing Dooo.sh/it Con

Posted at 4:32 PM by Max Cameron Startup 101

Let’s actually dooo.sh/it.

The Reason

I’m really proud to announce the inaugural dooo.sh/it Conference, where customer development and lean startups come to life, not where they come to talk. I’m all for dialogue, but I’m sort of over defending the merits of customer development. At this point, I’m already turning words into action, and this is an open invitation for any like-acting individuals to join me.

The Format

The biggest difference between dooo.sh/it conference and other lean meetups in Toronto is our emphasis on action, not reflection. We’re all about check points, not philosophy. So here’s how I see it shaping up:

Conference runs every weekend from Big Bang HQ.

Hours

• Friday: 5pm - When I go out dancin'
• Saturday: 9am - 6pm (we have a party to go to this weekend)
• Sunday: 9am - 5pm (gotta have some family time)

We’ll kick off each day with team checkpoints. Each team has 10 minutes. I will ask four questions:

1. Where are you in the cycle? Problem validation, or solution validation, or both?
2. What have you done since last week?
3. What have you learned?
4. What are you going to do next?

Any remaining time will be devoted to critical questions.

Then guess what? GO TO WORK. If you have validated assumptions - design or build your product. If you don't, get out of the office, go talk with your customers. Go get data.

The Prerequisites

Learning is the primary objective of this conference, but it’s not about learning lean or customer development. That’s your job. dooo.sh/it conference is about learning from your customers and taking action. And so, here are the prerequisites for attending this event.

There is a limit of five product teams.

1. You are actively running customer development for a product you’re building.
2. You have read Running Lean by Ash Maurya
3. You have created at least one lean canvas for your product
4. You have passed the quiz we’re in the process of writing.

EMAIL MAX AT BIGBANGTECHNOLOGY DOT COM if you’re coming over.

Thu 03 Mar
2011

Your Startup Needs Employee Benefits Part 2

Posted at 4:43 PM by Liza Mattimore Startup 101

When Big Bang Technology started out two and a half years ago, it was just Max and Cam. But in the last year, the growth of the company has created new challenges and opportunities for us to develop a company culture that supports everyone at Big Bang. Armed with that mandate, Big Bang set off to create a company health plan that would not only keep all of us healthy, but also address our individual needs.

All too often, companies approach health benefits in a top-down, dictatorial way. They base their decision making on the cost to the company, and not the needs of the employees. Employees are usually shut out from the decision making process because the thinking seems to be, the less they know, the better. But at Big Bang we’d like to challenge the “ignorance is bliss” model and suggest that small businesses actually have the advantage of size - they should use it by being inclusive about deciding on the structure of their plans.

But before we could even ask staffers about the benefits they’d like to have, we needed to do some preliminary research about our options. After arming ourselves with information about what was available, we scheduled a workshop with the gang to present our findings and get their feedback.

In order for our workshop to yield any real results we needed to approach it with thoughtful consideration, meaning that we needed to ask a lot of good questions. As a starting point, benefit premiums are based on certain variables. Variables such as age of employees and size of the company are fixed, at least initially. But there are independent variables like employer/employee contribution percentages, or level of extended health coverage, which at a premium level covers things like massage therapy. Those are the variables that we wanted to zero in on during the workshop. By asking the right questions of your staff you can gauge what their expectations are regarding a whole host of insurance issues.

We began by asking them general questions about what areas of health are important to them, and their basic regime. We broke overall health down into four subsections - Nutrition Health, Physical Health, Mental Health and Beauty Health - and asked everyone to rank those in terms of importance. We also did a word association exercise to expose our real health priorities.

Next we asked specific questions about health habits. Do they have regular check-ups with a GP? How about an eye doctor? Or the dentist? Is access to mental health support a priority? During the workshop we also asked the gang about what kinds of health expenses they were currently paying out of pocket. Would they rather pay a higher monthly premium to ensure they had unlimited access to those resources without paying out of pocket? (Those costs would be things like prescription drugs, eye wear, teeth cleaning and polishing, or even an appointment with a nutritionist.) Then we asked practical questions about health insurance and affordability. What level of contribution did they feel Big Bang should make? And what was a reasonable dollar amount per month that they could afford to spend on their company insurance?

We learned some very interesting things from our research, and even more from talking to everyone in the office about what their needs and expectations are. We learned that preventative care is not as big a priority to the insurance companies as it is to us. (Insurance companies, for example, won’t pay for the removal of pre-cancerous moles, although they will pay for your skin cancer treatment.) We also learned that some insurance companies will provide access to various private counseling services for a negligibly higher premium. This was a resource, we learned during our workshop, which was important to staffers.

But the workshop had a value beyond benefits. Not only did we learn a lot about the insurance available in the market, and what the Big Bang gang thinks about their own health and our potential plan, we also learned that doing exercises like this can strengthen our team. When you take a group approach to what might be considered a very personal thing - health - you build empathy into your team.

There is also the added advantage of having one plan for the entire team, which lowers our premiums. This is particularly important for small businesses, who typically get slammed with higher premiums simply because of the size of their staff. Collective bargaining with insurance companies means everyone gets the lowest rates possible, even if they are paying for coverage they themselves might not use. Some members of our team have vision problems, but by talking through the coverage options with everyone, the gang members with perfect vision are a lot less likely to resent paying extra to ensure we get the the highest coverage for vision care.

Getting a company health plan follows from the belief that we all spend most of our adult lives working; it is in Big Bang’s best interest to look after all of us, keep us healthy, and by extension, productive. It’s also the right thing to do.

Wed 23 Feb
2011

Why You Need a Co-Founder

Posted at 4:16 PM by Max Cameron Startup 101

It’s hard to launch a startup alone, but it’s even harder to find a co-founder to start it with. I’ve taken some lessons from the real world and I want to know: If you were looking for your perfect match, would you go to startup speed dating?

Debate Alert: Do you need a cofounder?

There is a hot debate circulating around the startup world about the value of seeking out a co-founder. Some authors argue that one should avoid having a co-founder at all costs. The author argues that startups with co-founders are more likely to fail because of design by committee, executive infighting and authority struggles. I would like to call bullshit on that article, but we’ll leave that for another post. There are, however, others arguing that there is no “i” in team, but there certainly is an “i” in fail, and that starting a company is simply too big a burden for one person to bear.

Without getting into the “marketing dude seeks technical co-founder” fiasco, which I haven't written about yet, I’d like to throw down and say that having a co-founder is a good idea. And not just because of the separation of roles that my man Steve writes about in relation to customer development.

Why it works for us

Anyone who’s met Cameron knows that he’s close to being a free electron, but he’s actually more dangerous than that. He’s a well-spoken technical guy who understands business. It’s a rare combination of skills. But the point is, he had the CV to go it alone, so why would he choose not to?

Support

Nobody likes to make hard decisions alone. This might sound like a cop-out, but it’s not. If you check out the two-man rule (should be two-person rule), you’ll see some interesting uses. The basic idea is to prevent accidents from happening and bad decisions from being made. We put out fires every day, so can anyone see the irony in the fact that fire-fighters run into burning buildings in groups no smaller than two?

Now let’s talk about dealing with the fact that you just took a giant risk by starting a company. Staring at the huge, abstract, unknown world of business is a lot easier to cope with when you’re doing it with someone else. That person is probably as naive as you, and is therefore a powerful source of courage. We are, after all, going empty-handed into competitive marketplaces that reward experience and insight, not passion and vision.

But what’s even more important is support related to your personal life. When an actual crisis happens, when your girlfriend makes you sleep on the couch, when serious family issues go down, that’s when you’re glad you have a partner. Someone that won’t give up on you when the whole world looks like a mess.

Competition & Accountability

Having a partner prevents you from being lazy. Let’s face it, it happens to all of us, and there is no motivating factor like having someone there who can snap you out of it. In my experience, having someone that has always pushed me to consistently improve and become smarter has been a strongly motivating factor.

If you came and spent a day at my office, there’s one thing I hope you would notice and remember. And that is the amount of raw and critical feedback that everyone consistently gives to everyone else. This is a very important pillar of our identity, but it’s a hard habit to bring out in others. Cameron and I have always been brutally honest with each other, but when we started growing our team, it must have been a shock for them. So how do you grow your team without losing your gusto?

Having a partner allows you to model interactions in your office that simply cannot be done with a single founder. The fact that I can openly and publicly criticize and be criticized shows the team that it’s ok to criticize, in fact it’s more than ok, it’s healthy and we all become smarter as a result. The same goes for instilling values of learning, fitness, camaraderie, and healthy competition.

Startup Speed-Dating

The beginnings of Big Bang Technology were accidental, if not coincidental. If one piece of a fairly complicated puzzle had been the wrong shape, there’s a good chance Cam and I would have never had the chance to do what we're doing. My bet is that there’s a lot of really great companies that don’t exist right now because the right people haven’t met yet.

I think it’s safe bet because we host a lot of people over to our office for lunch, and we listen to a ton of bright ideas. All these ideas really need is a little execution. So my big bright idea is this: Get a whole bunch of talented, eligible individuals in a room and set up conversation areas. Then you rotate through and talk to each person for 5 minutes. When the bell rings, you indicate a yes or no for that person on a sheet of paper and move on. Everyone’s sheets are then tallied, and mutual matches get notified after the event.

If you think I should execute on this idea, let me know on twitter.

Fri 11 Feb
2011

Your Startup Needs Employee Benefits

Posted at 3:07 PM by Liza Mattimore Startup 101

Since Big Bang Technology’s inception almost three years ago, we have been forced to learn a lot about business. Max and Cameron have done a lot to make Big Bang a great place to work. As the company started to grow, we wanted to take ownership of our employer responsibilities, and take a bigger role in looking after our team. With Chris's one-year anniversary looming, and the staff growing at a steady rate, it became increasingly clear that we needed to put some basic human resource infrastructure into place.

My first project was to turn our contractors into employees, which isn’t as hard as it looks. Once that happened, I was asked to put company health benefits in place. Beyond their practical benefits, a company health plan helps to ensure that employees feel protected and invested in the success of the business. But here’s the problem: how can we make a good decision about health benefits when most of the information comes directly from the companies trying to sell us their policies?

Typically, getting a health policy for your business means working with a broker who's incentive is to sell you a policy. Brokers are paid by the insurance providers, not by the company buying the policy, so they are not necessarily looking out for your best interest. Knowing that, how do you know what policy is actually best for your company or its employees? And who can you trust to give you unbiased advice?

We started by investigating fee-for-service brokers. Fee-for-service are the best available option because they're paid directly by the customer, and not the insurance provider. They can give you unbiased advice because you pay them directly, and they don’t have loyalties to any particular insurance provider. Unfortunately most fee-for-service providers won’t work with a company as small as us. Luckily, they were willing to give us a few leads to pursue.

Armed with a list of brokers, we trusted our instincts and set up a few preliminary consultations. In most cases you are not obligated to sign brokerage agreements until you decide to go ahead with a plan. So if any of them try to tell you otherwise, just cut them loose and move on to the next one. We found three brokers representing a variety of different insurance providers, and asked for sample quotes.

Sample quotes usually list several varied coverage options, and represent the extremes of the coverage spectrum. Typically, insurance companies have a basic policy, and a Cadillac policy that includes their minimums/maximums for extended health care, dental, and vision coverage. You can mix and match policies to suit your companies needs, and even tier your policies based on a variety of factors. However, the more people you have on the same policy, the lower the premiums become.

Benefit plans also require a minimum contribution to life insurance, accidental death & dismemberment, and critical illness. Companies can choose how much beyond the minimums they want to cover their employees for in the case of unforeseen emergencies. Using some basic information about employees, such as age, gender, and number of dependants, they can give you a rough estimate for what the policy will cost per employee each month.

The next step is to decide what level of coverage you want for your employees and how you want to structure your contributions. Because there are so many options and endless combinations of coverage plans, finding a plan that is right for everyone can be a challenge. Most providers require that employers contribute a minimum percentage, usually 33%, but we have also seen 50% minimums. In order to determine what level of contribution Big Bang was going to make to employee benefits we spoke to some of our peers who have set up programs like this in the past.

We were curious about how other companies like ours set up their health insurance policies and if they are happy with their corporate coverage. We made sure to ask companies of similar size whose employees were in our age group because those are the primary factors that influence premiums. Some of the questions we asked were:

• How have their benefit needs evolved over the years?
• How would they do things differently?
• How much variation in plans did they have across their employees?
• What percentage of the policy did they pay for their employees?
• Did they tier the company contribution for their employees over time, or did they give everyone the same contribution from the start?

Although it might seem obvious to consult employees about what their ideal benefits package might look like, most employers never ask. Employers are usually concerned about keeping costs down, and assume that employees always want the highest levels of coverage possible. But ultimately, choosing a benefits plan depends on the individual needs of each employee. The problem is that most employees our age have never given this any consideration. So instead of making assumptions about a very important subject, we wanted to include the whole gang in our decision making process.

To do this, we set up a benefits workshop for everyone at Big Bang to give us an idea about what our benefits policy should look like. We reviewed the policies available from various providers, and took time to understand the difference between them. We completed a confidential questionnaire to help everyone think about the health coverage they want. We also discussed the ideal relationship between and employer and their employee and what constitutes a fair employer contribution.

A lot of startups never think about offering a solid health benefits plan. Maybe they think that only established companies need them, or best case scenario, they think about them as an incentive to attract talent. We couldn't disagree more: having a health plan in place is absolutely necessary. Not only because we’ll be better off as individuals and as a company, but simply because it's the right thing to do.

Tue 08 Feb
2011

Defining the Value of Community

Posted at 8:20 PM by Max Cameron Community

Over the past two and a half years, we've come and gone through a number of meetups geared toward what we can call the "digital scene" in Toronto. More recently, we've become involved in LeanCoffeeTO, a group of small business owners that meet to discuss Lean Startup principles. I never expected it to be tremendously valuable, but that’s what this particular group has become. In this post, I've tried to articulate what I'm getting out of this meetup, and where I'd like to see it go in the future.

Defining the Value of Community

LeanCoffeeTO has become many things: a place to find great talent, an environment that creates exciting partnerships, and a startup support group where we can commiserate with like-minded people. I particularly treasure the satisfying and shared sense of disgust when we field the occasional pitch. There is a sense of purpose behind our meetings, and a pride in sharing ideas in a room filled with people you really respect.

The constituency of this group is at the same time homogeneous and tremendously diverse. All of the regular attendees share the desire to work hard and succeed, as well as the deficiency of common sense that typically accompanies the terrible term “entrepreneur.” I’ve met really interesting freelancers, two-person startups, partners from rapidly-growing teams, and even enterprise mavericks who are still deciding if they want to eat the red pill. There's even a tele-commuting software dude who keeps a good LeanCoffeeTO twitter list showing more attendees I couldn't link to here.

This meetup, more than anything, is a place where you can learn new ideas that can be directly applied to your business. I have learned about concepts that I had previously dismissed, discovered new authors who now influence the way we think about business, and have enjoyed sharing our experiences as we all learn more about the ideas that will shape our future.

I would like to see the group continue to evolve at its natural pace, and don’t think any abrupt change is necessary. However I’ve started to derive more and more delicious value from certain aspects of the group, and will do my part to foster those themes moving forward.

Transparency

I would like to be able to share very specific information about my company in order to gain more insight from the group. The feedback we received from our first case study has been invaluable, and it would be awesome to really open up the hood to see if what we’re doing is small beans or big potatoes. I would also be very interested in learning more about our peers.

This has got to be more than a revenue-measuring exercise, but really poignant advice requires real data, and real disclosure. A few things I would like to share and learn out about are:

• How much money we are saving at the corporate level, and why.
• How are other companies putting together benefits packages for employees.
• How employees can "move up" in small companies.
• How we structured our shareholders agreements.
• And of course many, many more.

Depth

So what I’m looking for is not just more transparency, but also way more depth of discovery. Discussing one topic, let alone some of the more complex topics I mentioned above, would be a very difficult task for a group of 20 to accomplish in an hour. And that’s unfortunate because the format of the meetings are effective and packed full of information. But regardless of the where we meet and for how long, there is a more fundamental element that has to be in place for this to work.

Trust

It is really critical to have trust in your outsourced advisory board. This trust goes way beyond “Oh please don’t steal my golden idea.” I’m more concerned with having a group that actually cares enough about each other to call bullshit on each other when it really counts. Because sometimes good advice is hard to give, and sometimes even harder to take. It’s also about making a commitment to give as much back to the group as we all receive. Personally, I’m willing to help any way I can.

And if LeanCofeeTO didn’t change a damn bit, I’d still be there any morning of the week.

Find me on twitter if you'd like to parlay a little bit more.

Tue 08 Feb
2011

Financing Your Startup without Bootstrapping, Incubation, or VC

Posted at 11:37 AM by Max Cameron Startup 101

Imagine us, deciding to start a software company, without any experience, resources, or a golden idea. I told this story at LeanCoffeeTO a few weeks back, and since it was well-received, I'd like to share it with you here.

For the sake of this article, let's say the objective of a startup is to build a piece of software that can make a lot of money, or attract a lot of users. And let's also assume that building a piece of software that can accomplish these goals needs significant time and energy to slip into profitability. Finding a way to sustain the company until that time arrives is just a reality of doing business, and that sustenance comes in many forms. I believe this is the defining question for any startup, and the answer you choose will influence the startup you build.

I also believe that the dominant models of startup funding are either unrealistic, or adverse to the interests of its founders. Of course, there are benefits and disadvantages to every option, but our decision to pursue a different business model has given us a lot of flexibility and protection that many other funding models were not designed to provide.

Bootstrapping

If Bootstrapping was realistic, it would be the best option available. Unfortunately, it requires that you know what you’re doing. There are two ways to bootstrap your company: save a lot of money and stock up on top ramen, or keep doing client work while you build your product on the side.

If I had enough money saved to keep a company going for a few years, I would already be rich. But there's another problem: working for free is demoralizing for a company. I want to pay my team, my partner, and be paid myself. Earning your keep makes you work like a champ.

Doing client work to pay the bills while you build "your product" isn’t impossible, but it’s unlikely to happen. We tried to do it, and it didn't work. It's impossible to give your product the attention it deserves while you're devoting your most creative hours to your client's projects. Building and selling software is a full time job.

I've met countless smart people who have been dreaming of building their own piece of software for years, and I hear the same refrain at every meetup. "This site we're building out for client X is taking up all of our time, but it's the last one, I promise." Maybe if you didn't lease that two-thousand square foot office and start that family you'd be able to cut the strings a bit earlier.

Investors and Incubators

There is absolutely no shortage of incubators (even in Toronto) and investors waiting to get their hands on young talented minds and the ideas that rest inside them. A quick look at how some of these groups looks at startups is enough to turn me off. And while some of them are pretty cool, they're hard to get into, especially if you don't have some interesting credentials. But for people like us, without an understanding of customer development or a truly golden idea, we were out of luck.

I see two major ramifications of seeking outside investment to facilitate the development of a startup. The first is that you’re now accountable to a board rather than to your customers. Even prominent investors are lamenting about the utter lack of any professional standards, resulting in bad board members leaving a trail of broken companies behind them. More importantly though, working in a pressurized environment must make it hard to take chances, learn through discovery, and pursue many experiments.

More importantly, outside investment means giving away a piece of your company. This is your baby, the thing you’ve nurtured and cared for and shaped. Would you give away a piece of your real-life baby to make it successful later in life?

The Partnership Model

In the summer of 2008, Cameron and I were hired as part of a rag-tag freelance team that was cobbled together to build a web app. The project came about because a successful offline company that had been doing live event training in the automotive industry wanted to deliver their training online. The project fell apart pretty quickly, but when Cameron and I tried to quit, we were offered the chance to start from scratch, and so much more.

Here’s how our relationship is structured:

• The product is wholly owned by our client.
• We have two contracts in place: A standard professional services agreement, and a separate royalty agreement.
• The PSA states that we bill for our expenses and our hours (at a reduced rate) every month.
• Quarterly, we subtract that amount from the gross revenues generated by the product.
• Our royalty agreement states that we receive 20 percent of the remaining net revenue, the remaining 80 percent belongs to our client.
• Either party can end the PSA without too much hassle, however the royalty agreement continues in perpetuity.

Why it Works for Us

We benefit tremendously from the domain-knowledge of our client. Since they have so much experience with corporate learning environments, they play the role of customer as well as a business partner. Because of their reputation and credibility, they also open a lot of doors for our product.

Our arrangement also lets us focus on our strengths, designing and building products for the web. They in turn can focus on managing accounts, and providing other consulting services to our clients.

And while we have to compromise to some extent in the specific direction the product takes, and what features will be included in the next release, it’s a collaborative relationship filled with good ideas and lots of debates. And once the features are decided on, we’re very fortunate to have partnered with a company that gives us a tremendous amount of autonomy to design and build software that satisfies the requirements we build together.

Disadvantages

Every relationship has its disadvantages. The first, big, obvious disadvantage is that we don’t own the product, and we don’t receive 80% of the net revenue. However, 20% of a million dollars is a lot more than 100% of fifty thousand dollars.

We also don’t have exclusive control over deciding the direction of the product. Don’t get me wrong, we definitely have a strong voice at the table. But guess what? The only people that decide what features are really useful are paying customers.

Conclusion

In our opinion, the opportunities and benefits this deal brings to Big Bang Technology far outweigh the disadvantages. Especially when you consider the alternatives. We feel like we’re living the dream, building software used by major companies in the United States, and more importantly, we’re using these opportunities to learn and apply customer development principles.

A lot of our friends have raised concerns about the “repeatability” of this model. How often can you find a successful offline business willing to invest in a product, offer such generous terms, and trust a company like ours who doesn’t have a proven track record? I don’t know, but if anyone here has any doubt that it is possible, I hope we’ve presented a compelling case.

Please feel free to yell at me or praise me on my twitter account.

Thu 03 Feb
2011

Daily Feedback is more important than Traditional Performance Reviews

Posted at 2:36 PM by Cameron Westland Startup 101

Chris Mudiappahpillai has been with Big Bang Technology for one year. Because I love Chris and the contributions that he has brought to our team I wanted to do the right thing and give him a proper performance evaluation. As his anniversary was approaching I began to reach out to our advisors and research how we should be assessing his performance. I saw that there were a million processes and procedures for evaluating an employee and it got messy. I decided to get back to the basics and form the basis of his evaluation upon a single question: How does Chris know he is succeeding each day?

I started to wonder if this question was even important. Does it matter if he knows whether he is succeeding? My instincts told me that this was very important but I had trouble when it came to articulating it. Like usual, my mind began drifting towards video games.

Modern video game design is essentially the act of balancing a set of feedback mechanisms in response to user gestures. Studies have shown that pure positive feedback mechanisms yield the highest rate engagement for video game players. You don’t have to be an expert to see that games like FarmVille or World of Warcraft are extremely engaging. I was surprised when I realized how engagement affected employees as well.

Engagement is almost like being turned on. An engaged employee is fully involved, enthusiastic, and will act in any way that they can in order to help the business. What this means is that if frequent positive feedback has created high levels of engagement in video game players, it should theoretically do the same thing for employees. So how does an employee get feedback in a typical company?

Inside of many large companies (or small business trying to emulate large ones) employee's tasks are fairly independent. There might be a weekly stand-up, or town hall where companies rally around common objectives. A team meeting will be called where people announce factors that are “blocking” them from proceeding on a task, or that might be jeopardizing a deadline. The problem is that there isn’t enough positive feedback and it’s also not the right kind.

There isn’t enough feedback because of what catalyzes it in the first place. Most managers don’t want to get involved until there is a mistake. A friend who is a manager once told me that “standing there with their arms crossed while the well oiled machine went to work” was the ultimate goal of a manager. That is great except the manager is missing so many opportunities for positive feedback.

The feedback is also the wrong kind because of where it comes from. Positive punishment is doled out when an employee makes the mistake and it usually resembles something like “Bad dog!”. Negative reinforcement is also used frequently: “If you mess up, we are taking away your bonus.” Nothing disengages a person more than positive punishment and negative reinforcement. And when an employee does something great? Well finally, that is their job anyways isn’t it?

There is a better way. We shouldn’t be looking at big companies as a model for us. Small companies aren’t the same as big companies anyways. How can we use the fact that we are small to our advantage and leverage that uniqueness? Giving constant positive feedback should be the mission of every start-up founder. Here at Big Bang Technology, we’re already using a process called Doing the Board which gives feedback every morning as the team gets to work. Moving forward it’ll be our job to make sure that feedback is as positive as possible. Whatever you call your process, it literally doesn’t matter as long as you as your giving positive feedback.

So after all this work to figure out how I’m going to review Chris, I realize that we’ve been doing it already one day at a time. That might explain why he seems to be very engaged. But what about the bigger picture? How do we plan for the longer term things with our employees and how do we make sure that they know they are on track? These are great questions and I will try to answer them in the next post.

Tue 04 Jan
2011

Why Your To-do List is Broken

Posted at 3:28 PM by Liza Mattimore

Everyone knows that projects fail because of poor planning and poor execution. But what you don't know is how your to-do list might be to blame.

Writing good tasks matter

As a small team working on big projects, keeping our daily tasks organized is critical to our success. One of the biggest challenges with traditional project management is the disconnect you can feel between your day-to-day activities and the overarching project plan. We’ve learned that no matter how many to-do lists you have lying on your desk, they’re all absolutely useless if they’re full of poorly defined tasks. 
We continue to struggle getting this right, but we’ve started to notice some trends we’d like to share with you.

Do it as a group

Every morning we have a short meeting where members of the team list what they hope to accomplish in a day. Accountability is one of the fundamental advantages of doing your daily task lists together as a group.

Explain it to a four-year old

Every member of the team can understand a well-defined task. It shouldn’t matter if you’re a developer or a project manager, it should all be crystal clear. 
If the task is complex, ask the person to explain it. They’ll end up having a better understanding of what they hope to achieve by vocalizing what they would normally keep hidden.

Work on project X


Another key distinction of good tasks it that they have an outcome. Remember high school? I do too. A well-articulated task has an object, subject and a verb. This makes your task accomplishable. 
And lastly, a good task will be time-boxed. The best measure of a task’s quality is that it gets finished on time.

Bad Tasks

Poorly defined tasks, by definition, do not get completed on time. When a task is poorly defined it often causes frustration, or what Max likes to refer to as, “face-palming.” 
One primary characteristic of a badly defined task is being bottlenecked. Meaning, you are unable to continue working on the project because some external factor is missing, i.e. waiting on budget approval. Another factor might be that you’ve defined a task too broadly. Build the website, would be a good example of a task that is too broad to be accomplished in a day. Or perhaps, the task was not really relevant and should not have been included in the first place. Being critical about the way you define your tasks is what takes them from being a meaningless to do list and can help unclutter the day so everyone is on the same page.

Why is this important?

At this point it should be fairly clear that not getting tasks completed leads to failed projects, and ultimately to failed companies. Just being organized is not enough. Being critical about how we define our tasks takes us beyond simple organization, and makes our days much more productive. By critically planning our days we ensure that projects get finished on time. Knowing the difference between good tasks and bad tasks is fundamental to that success. And it has become so integral to the way our business operates that we thought it might be useful for other small teams out there.

So, happy tasking!

Mon 13 Dec
2010

Now hiring: Full Frontal Interface Developer

Posted at 4:35 PM by Adam Doeler Community

From the desk of Max Cameron,

Big Bang Technology is a small software design and development company based in Toronto, Canada. We are currently five people, hoping to reach level seven in the coming months. We are two and a half years old and we hope to be in business for another ninety-seven and a half years.

We build a rapidly-growing eLearning platform being used by large and small companies.

We are looking for a full-time Front End Interface Developer to join our skilled team. You will be responsible for developing, refining, and improving the user interfaces. Additionally, and quite significantly, you will work closely with our engineer Adam. Adam is cool. Bonus.

Our vision is to continue development in Flex, with plans of moving to HTML5 in version 2.

Our Expectations:

• Create wireframes as proof of concept
• Implement wireframes
• Desire to continuously improve and learn

Your Skills:

• Experience developing in Flex
• Strong Photoshop skills
• Understanding of user-centred design principles

Attention Grabbers:

• Designer turned developer
• Experience with Ruby on Rails, and version control
• Working examples of what you can do
• Good personality who will make our team smarter and cooler

We Invest in:

• Our work environment
• Our continued education
• Our personal and professional happiness

We are located downtown Toronto, ON - in a sweet open concept space.

Our Team:
@camwest
@maxcameron
@mud
@releod
@liza101

Creep away my friends!

Make a video demonstrating why you're the best candidate.
Or if you're shy, email max (at) bigbangtechnology.com

Mon 18 Oct
2010

Feature Control: Deploying Woople Bookmarks

Posted at 1:06 PM by Max Cameron Programming

We deploy features from our master account straight from the UI like a gangsta.

Wed 13 Oct
2010

Introducing Big Board App

Posted at 6:42 PM by Max Cameron

We're replicating our whiteboard technique as a web service. And boom.

UPDATE: Please visit our new website and sign up for notifications, or find us on twitter.

As described in previous articles, for the past year and a half we've started each and every morning with a brief exercise we've always called "Doing the board." In this short daily planning exercise, we use a whiteboard and a colour-coding system to help understand, correct, and predict our daily productivity. Please take a moment to read about our methodology and its initial response by the community.

Here's the news: we recently started working on a project in our spare time called Big Board. Our goal is to make a high-fidelity transfer of the way we use our whiteboard. I've been beating the bush lately trying to test our technique in our community, so hopefully I'll have some feedback and reports to share with you.

Also we'd like to open up about how we're building Big Board. We don't talk too much about our other project, but hopefully Big Board will allow us to share more practical information about how we're building a lean/agile product.

So, here's the fourth iteration of a wireframe that Cameron made. One small step towards tangibility.

Wed 13 Oct
2010

Feature Control

Posted at 2:26 PM by Adam Doeler Programming

We’ve recently changed how new features are released to our production environment. A new system has been introduced into our application titled “Feature Control”.

History

Our application codebase is generally split into two branches, master and development. Most of the work occurs in development; when ready the changes are merged into master. From there we deploy the master branch to our production environment. Our users now have access to the shiny new feature.

This workflow works well for us, but misses one important element when releasing a new feature: Beta Testing. Up until recently we had no way to gradually rollout features to a subset of our users. Our releases went to all users immediately. This is scary — feedback is essential when changing how a user is going to interact with the application.

Why?

I’ll admit it, my initial thoughts when I first started to hear how other applications and services implement similar systems, were skeptical. Scattering if statements all throughout your code, a separate dashboard, a key/value store, user buckets to manage features, it felt wrong… too many moving parts. Something was bound to break. It just so happened my confused mental model broke, and I saw the light!

Some of the benefits we’ve already experienced in this new system's short lifetime, have been:

• Free regression testing. Even though some features are not released in production for all users, the code still lives inside the system. We’ll have a much better idea if a new feature causes any trouble.
• Gradual rollout of features. We can easily enable or disable a feature to collect feedback and improve.
• Ability to enabled/disable features through our UI without engineer intervention or a full deploy.

How

At this point Feature Control manages features in the UI only. While this works well for us currently, it could be extended to control functionality in the backend as well.

When one of our users loads the application, we determine if they have beta access to any features, and grant them access (see Beta image below). Once set, the User IDs will persist between feature states. If we rollback from beta to disabled and then back to beta again, we do not need to re-enter the IDs a second time. When a feature is marked as disabled, nobody is granted access, no checks are performed. When a feature is marked as production, everybody is granted access. This is similar to Forrst's Bucket concept.

I’ve included a couple screen shots below to help visualize how we manage features from the UI.

We still use the same development-to-master workflow, only now we can merge the codebase back into master at a much higher frequency. Flickr embraces a similar paradigm, only they are not using branches.

If your team implemented something similar, let me know.

Fri 08 Oct
2010

Day Planning for Small Teams

Posted at 3:02 PM by Max Cameron Project Management

Now with two-hundred percent more rainbows.

UPDATE: Please visit our new website and sign up for notifications, or find us on twitter.

Please post comments or ask questions about this article here.

I was impressed at the amount of attention our first post received from the hackernews community, as well as the response from our local networks. As you can see from our analytics, we discovered a lot of people are interested in the idea of day planning.

The responses we received fell into three basic categories: this smells like micro-management, this doesn't deal with the hard part of planning, and, this is interesting so maybe I'll give it a try.

The Response

Ben Metcalfe responded by writing, "I think the granularity they are suggesting feels a little too micro-management like." Mike Ryan goes on to say much the same, while making allowances about the value of tracking non-technical tasks.

I think we reached a nice compromise in our discussion thread and I thank them for helping me refine the way we're explaining our concept. I agree I have to do a better job at explaining the granularity idea better, but this technique is definitely not a management technique.

Micro-Management

Doing the board is not about managing people.

I think managing people is caring about your team, empowering them to make decisions, and helping them realize and improve their projects. Managing has nothing to do with day planning.

Day planning is about people learning to measure daily goals, celebrating their completion, and understanding their incompletion. Ultimately, planning your day is a way to interpret your workload and carve out the best path through it. It does, however, have some other implications for your team.

Transparency in a team can sometimes be uncomfortable. I know teams that don't share as much as we do about what each person is working on. I don't understand that.

It also became apparent that a lot of people associate negative connotations with task management. It's a common myth that you have to be extremely disciplined to get anything out of it. But that's another benefit of day planning. It's ok if you mess up, or forget about your board. Just erase it and start over.

Project Planning vs Day Planning

Planning a project is a completely unrelated to planning out your day. Day planning isn't about brainstorming features, researching ideas, creating and debating concepts, and finally deciding on a release plan. These activities exist at a much higher level.

We also have no desire to compete with products like pivotal tracker, things, or teux-deux, because they solve entirely different problems. Our technique is more like the "Today" list in a personal task management system, although ours is team-focused, and incorporates a colour-coding technique. And finally, our system has a nice benefit of self-correction that other task management systems lack, whereby ill-defined tasks draw attention to themselves by their incompletion.

This is interesting

My hope is that people who read these articles will take a leap of faith and decide to do the board for three or four days. I've even offered to lead daily planning meetings for free at any company (tech or non tech) in downtown Toronto. If you're interested in having me over, please reach out.

The amount of feedback (both positive and negative) is showing us that we're on to something useful. I look forward to hearing about your experiences doing the board.

Wed 29 Sep
2010

Rails 3 upgrade - A Retrospective

Posted at 8:56 AM by Adam Doeler Programming, Tutorials

UPDATED: October 11th, 2010 Now with more working code!

August 29th, 2010 was a glorious day for Rails developers around the globe, not only because it is my birthday, but also because Rails 3.0 was officially released. I would like to send congratulations and thanks to all 1600 contributors that helped make this release a reality.

I’ve spent the better part of September upgrading our main application to Rails 3. My hopes are that you will read this and gain some insight as what to expect when upgrading your own application.

Baby Steps

Luckily for us, just as I was about to dive into this project, Rails 2.3.9 was released, and said to make the upgrade process easier. This seemed like a great first step. I upgraded to Rails 2.3.9, and fixed a few minor deprecations that were introduced in this version.

We use Paperclip extensively within our application, the latest version 2.3.3 works with both Rails 3 and Rails 2.3.x. I upgraded this gem, as it seemed and was a quick adjustment.

All tests pass at this point, time to move onto Rails 3.

Gem Research

I should mention before I actually started touching code; time was well spent researching our gem dependencies and plugins. I wanted to ensure we had full compatibility before this upgrade process occurred. A simple chart was created listing all our gem dependencies and plugins, if they work in Rails 3, and if not what actions were required to make it work.

To test the gems and plugins, I setup a blank Rails 3 application, and manually built up similar context to what our actual application has. Looking back this was fairly time consuming. Though it seems like the best approach when you don’t want to make a mess of your existing codebase.

Authlogic had quite a few deprecation warnings, but for the most part it worked, until I tried using the AuthenticatesMany module. This outright failed, so more research was needed. I ended up forking the repository and pulling in some fixes from other contributors. Still waiting for a pull request to be accepted. As of now, Authlogic is working in our Rails 3 application.

I forked NestedHasManyThrough, and made a bug fix. This resolves an issue where the plugin fails when using polymorphic associations. Waiting on a pull request here as well.

Overall, the initial gem research was about 90% effective.

Upgrading

My first task was simple, I created a new Rails 3 application on top of our existing application. Since our application is kept in version control, this seemed like an easy approach. Merging differences usually produces expected results, while using an external upgrade plugin may produce unexpected results. Overall the merging approach was quick and quite painless. This felt like a big win.

Next in queue was to move the gem dependencies out of the config/environment.rb file. Bundler is your friend. Simply move the gem dependencies into the Gemfile. I’ve put our .bundle/config file in version control to ensure all developers get the same bundler setup regardless of machine.

Following that, I upgraded the files in the config directory. Some of the changes merged in from installing Rails 3 on top of our application needed some minor syntax changes. The router was the biggest change in this directory, but the new DSL is easy to translate from the old router DSL. My hopes with the config directory is that by changing these files as needed, it would lead to the application being bootable in the shortest amount of time.

My approach with the router was to disable all routes, and convert one resource at a time, while testing the actual application. Obviously the first component that failed would get moved into the new router DSL and fixed accordingly.

Finally I upgraded all our models and controllers to use AREL. Thankfully, our controllers are very light, so almost no AREL changes were needed here. Our models are thick and juicy, and had my attention most of the time. I also moved our mailers out of the models directory and into their own mailers directory which is now the default.

The controllers needed virtually no updates, aside from moving filter_parameters into config/application.rb and some to_json adjustments (see below).

Pain Points (Rails3 Specific)

Due to the nature of our application, we render JSON responses on almost every request. This was also our first big gotcha. In Rails 2.3.x we called to_json directly in some controllers, and passed in a hash of options used to return a specific representation of the object. This method was defined in most of our models. Rails 3 now calls as_json on each object in order to get the JSON representation. In order to resolve this, I went through each controller and adjusted where we called as_json vs. to_json. For our application this meant as_json was called on individual objects, and to_json was called on collections of objects. In some cases, neither method is called directly because the default JSON representation is acceptable.

I should also mention, that the as_json method normally returns an object easily converted to JSON, our implementation currently returns an actual JSON object. Your application may not need any adjustment here.

One of our key features is the ability to generate a CSV progress report in real-time. These files are often quite large (20MB+ ) and a generated on the fly, as the client downloads them. In Rails 2.3.x we simply called “render :text =>” and provided it a Proc. This allowed us to write to the Proc, and in-turn, stream the content as it was being generated. Quite effective. In Rails 3 this no longer works due to how the :text responder converts the output to a string. I created a custom responder that behaves like the Rails 2.3.x functionality.

The code samples below are based on what we are using now, feel free to adopt.

I am still interested in hearing if there is a better solution, but for now this is working well.

Pain Points (General)

When this project was originally planned, I had estimated roughly a week to upgrade to Rails 3. However, as the project unfolded; unforeseen issues surfaced (gem in-compatibility, Rails 3 behavior changes, etc) it pushed that original estimate out of scope. The plus side is that my time-boxing skills improved drastically. What was originally a single task (“Upgrade to Rails 3”), quickly became broken down into smaller obtainable daily tasks.

I started this project on September 1st, and had the application deployed on our staging environment by September 23rd. It is difficult to measure the size of this application in a broad sense. So with that in mind, our application has almost no views outside of a login screen, and everything else is a JSON response.

In conclusion, I hope that this article gives you (fellow Rails 3 up-grader) insight into some of my pain points and wins while upgrading our application from Rails 2.3.8 to Rails 3.

Feel free to contact me @releod

Sun 26 Sep
2010

Doing the Board

Posted at 5:42 PM by Max Cameron Project Management

A deceptively simple daily planning exercise is our most important process.

UPDATE: Please visit our new website and sign up for notifications, or find us on twitter.

UPDATE: cool conversation happening over at our hacker news post. Feel free to join in with your thoughts and opinions.

UPDATE: As requested, photos are at the bottom of the post.

A Simple Idea

About a year ago, our friend Jason taught us this really cool trick. He turned to us and asked, "Hey, what do you want to get done today?"

I replied something like, "I have meetings at 11:30 and 2, and I have to do a round of feedback on the new homepage. Other than that, I've got to update some documentation and do some QA. Oh yeah, and there's that form I need to sign and email to the accountant."

Jason wrote a few line items on our whiteboard and turned to Cameron. "How about you?" Cameron replied that he had to fix two bugs before starting to build a new feature. So Jason wrote those tasks on the board as well. As we moved through the day, Jason would put a nice checkmark next to each item on our list, indicating it was completed.

I didn't appreciate what had just happened at the time, but now this simple ritual is at the core of how we work. Our approach to this activity blends elements of a typical scrum meeting with organizational methods inspired by GTD. Since we've tweaked the process a bit, I thought it would be worthwhile to share with you too.

The Three Colour Model

Day 1: Red Marker

It's a Monday, and the whiteboard is empty. I stand and ask each person what they want to accomplish today. The goals are written on the board with an empty box next to each. It shouldn't take more than five minutes for a team of five. As we accomplish our goals, we check the box next to each task. At the end of the day, it's satisfying to see an artifact of the day's work.

Day 2: Blue Marker

We arrive at work on Tuesday, and erase all of yesterday's items, but only the ones that were completed. We have to leave the tasks that were not accomplished written in yesterday's colour. Then I grab the blue marker, and collect the team's daily goals during another five minute planning session. We work throughout the day and treat it like Monday.

Day 3: Green Marker

It's Wednesday morning, and I'm erasing all of yesterday's completed tasks. There's two blue tasks that were left unfinished, and one red task leftover from Monday. The red task is staring at me, looking real ugly, taunting me. It means one of two things: the task was either too big, and should be split into multiple tasks, or, we're bottlenecked and need to get it off our plate. No task should sit uncompleted for more than two days.

Weekly: Orange

At the top of the board we keep an area for weekly tasks, which do not follow the colour coding system. Always orange, typically a list of loose ends that can be wrapped up in one massive friday-afternoon effort.

Task Granluarity

The hardest part of this system is getting the "granularity" of your daily goals consistent. But this is also where I derive the real value from this system. You don't want to micro-manage yourself, but having specific success criteria is extremely important. There is a learning curve, but it's a valuable lesson. Our general rule of thumb is to accomplish about three to five goals in a day.

Example: Good Tasks

• Update functional test
• Feedback session for collateral project
• Integrate visual elements on homepage
• As a user, when I press pause, the video pauses.

Example: Bad Tasks

• Build the website. Way too big. How about, code the rollover states on the landing page.
• Write email to chris. Not big enough. Would it be satisfying to reflect on this task at the end of the day?
• Work on project X. What part of the project are you working on?
• Start working on marketing strategy. How about, call three customers and ask them how they've used our product to solve a problem.

Why We Do the Board

Listing and publicly exposing our goals makes us more likely to accomplish them. It also gives us concrete criteria for having a successful day. Before we started doing this, I didn't know why I was having a good or bad day. Now I do, and that's awesome.

Structuring our day before we kick it off let's us stop worrying about what we're going to do next. It's like test-driven development for operations.

It's fun and satisfying to check those little boxes off. I always say "annnnd… boom." right before I check it off. It's also great to know what your team is up to, and know they're making progress right alongside you.

There is no penalty for not accomplishing a goal. But, much like pivotal tracker, the system is self-correcting. Consistent micro-planning sessions creates a great feedback loop that makes us better at estimating what we can and cannot get done in a day. I feel that I'm more likely to meet my larger commitments, and protect myself from commitments that are impossible to meet.

I'd like to write a few more blog posts about this topic, and specifically about:

• Doing the board isn't the same as personal task management
• Doing the board doesn't compete with Pivotal Tracker
• How to choose good tasks
• "Knowledge workers" can do the board too

Feel free to get in touch any time.

Fri 20 Aug
2010

It’s a privilege, not a right.

Posted at 10:21 AM by Max Cameron Community

We've been working with a fantastic designer who goes by the name Mike Precious. He comes strongly recommended.

Let me say this - working with Mike inspired me to become better at what I do. You don't get that feeling from working with an agency. His obvious talent aside, it's his personality that sets him apart from the rest. Not only would I trust him with my logo, I would trust him with my children. He must come from a hard-working, honest Canadian family, because he never let me down, and as we all know - you can't buy trust.

With all of my admiration,

Max Cameron
Big Bang Technology

Mon 09 Aug
2010

How we implemented Continuous Integration on Engine Yard Cloud

Posted at 10:18 AM by Adam Doeler Programming, Tutorials

I was recently tasked with making Continuous Integration a regular citizen in our daily workflow.

You can find infinite writings on the web in regards to Continuous Integration; this one is specifically aimed at helping you get setup on Engine Yard Cloud using CI Joe.

Our application is hosted on Engine Yard Cloud, I believe they spoil us by making certain tools available (namely Chef recipes) when deploying an application. After reading this how-to, expect a smooth deploy process, while skipping the need to shell into a server and edit files manually!

If you are not sure what Continuous Integration is, or why it is important to have in-place, Wikipedia's Continuous Integration entry is worth a read.

Some of the code and ideas outlined were influenced by Chris Parsons Article on Running Multiple CI Joe instances with Rack and Passenger. I highly recommend you read through it as well.

The first step was evaluating the available options: CI Joe, Integrity, Hudson, & Cruise Control. The pros/cons of each option is beyond the scope of this post. We decided on CI Joe as our Continuous Integration solution as it is extremely easy to setup, and has a very understandable codebase.

Step 1: Fork It!

Fork the following Github repository "ci_server", and update the settings specific to your application. Review the README, as it explains the files you will need to configure to your needs. Sorry, no global settings file yet.

Step 2: Engine Yard Application Setup

Engine Yards Guide: "Attach an App to an Environment" will walk you through setting up your application. If you haven’t made it that far yet, take a look at their Getting Started guide.

Two important notes:

1. Select RACK as the Application Type
2. Under “EDIT ENVIRONMENT” select “CLI Deploy” process, this changes the default behavior of the deploy and rebuild processes. You normally select this after the application has been added to an instance.

Step 3: Custom Chef Recipe

Engine Yard Cloud gives you the ability to hook into the extensive Chef library, which gives you limitless possibilities when deploying an application. This is an essential part of a smooth deployment process.

If you haven’t setup a custom chef recipe before, Engine Yard Docs has everything you need to get started. Specifically, their entry on Creating Custom Chef Recipes.

Now that you have a basic understanding of Chef Recipes; create your own custom recipe named “ci_setup”:

This chef recipe is run when you rebuild your instance, and it will generate a test database connection, and checkout the repository you need to test against.
I’ve included an example Chef Recipe in the “ci_server” repo you forked above. Move this recipe into your own repository and push it to Github.

When you’ve finished editing the Chef recipe, you’ll need to upload the recipes to your server. Again, Engine Yard has documentation on this as well. If you have the Engine Yard gem installed simply run this command:

Step 4: Github POST-RECEIVE Hook

The last step of this guide is to configure Github to send a Post-Receive hook to our Continuous Integration build. On Github, click the “ADMIN” tab within your repository. Select “Service Hooks” from the options on the left side of the page. Select “Post-Receive URLs”, and complete the form with the URL of your CI server (which you set when adding the application in the Engine Yard dashboard).

Now, anytime a new commit comes into the Github repository, a POST will be sent to your CI server and the tests will be run.

This was our first implementation of Continuous Integration, if you have any suggestions on how this could be improved, tweet me @releod

Wed 07 Jul
2010

Big Bang Technology Second Anniversary Party

Posted at 11:00 AM by Max Cameron Community

It's been two years since we started our company. This calls for a party.

Feel free to join us for a party this Friday, July 9th, at 6pm, at Hotshot Gallery, at 161 Augusta Avenue, Toronto.

We'll have cool drinks, lots of tunes, and plenty of good people to meet.

Since this party is all about giving back to the community of people who have helped us over the past two years, we would like to continue extending that spirit of generosity. So we're also going to be collecting monetary donations for a very worthwhile charity called Little Geeks. Little Geeks collects, refurbishes and re-distributes donated computers to children in need. Any donation - no matter how small - will help this organization get through some tough times.

See you on Friday.

Best,

Max

Mon 17 May
2010

I love it when you find bugs

Posted at 3:59 PM by Max Cameron Startup 101

Writing good bug descriptions isn't easy, and developers love to bitch about bogus bug reports. But really, it's our job to help people report them better. How's a civilian supposed to know that sometimes we think in lists, and not in stories? We work with a distributed team, so they can't just sit down next to us and walk through it. When they find bugs, it's our job to hunt them down and squash them with impunity. I wrote this letter to our team-members to help me reproduce bugs without lengthy skype conversations or tons of email. This isn't for customer consumption, but rather for our internal team. I figure we owe it to them to help them write better bug descriptions.

Hi everyone,

Disclaimer: This message was not written with anyone in mind. I tagged everyone who frequently helps me with bugs, and I think it will help everyone.

Ok, on with the show.

I love it when you find bugs.

Finding and squashing bugs makes our product better. Even though it sucks when something doesn’t work the way you expect it to, it’s far better for us to find bugs than for our customers to find them. When you report a bug, my job is to make it happen on my computer. When I can do that, I can stop our developers, reproduce the problem, and get them working on a fix. When I can’t do that, I get frustrated because I can’t help you even though I really want to. The key to fixing bugs is for me to reproduce the problem. I was hoping I could ask you for a favour in helping me do that. I’d like to set up a consistent and simple way to describe bug-like-behaviour. And I think we can do it without using crappy bug reporting software with hundreds of drop-down menus.

Example time. Everyone loves examples!

Let’s say I try and add a user and it doesn’t work. One way to write a bug report is to tell a story. “Hi Max, I logged into the application and opened up the account manager and I added a user but the little spinny circle kept on spinning and nothing happened. So I opened up a different tab and logged in again and added another user and the same thing happened, but then I switched over to the content manager and came back, clicked a few different users, then I clicked on the first user and there she was!”

Umm ok. Let me get back to you.

Pretty simple bug, not so simple for me to reproduce. I know I have an issue with browser tabs, I know I have an issue with a spinny circle, and I think that if I select a few different users something might happen. But there’s so much I don’t know. So many steps missing, so much context absent. I’ll probably be sitting around hoping that I’ll stumble across the problem. I might call you and ask you to walk me through it (spending more of our time). More likely though, I’ll just try and “figure it out,” face-palming because I can’t help you get the software you need.

And this is just a simple bug, never mind the really juicy, complicated ones.

Here’s an alternate way to log the bug.

A list! Everyone loves a list!

"Dear Max, I found a problem. Here’s the steps I took to reproduce it."

1. Log into xxxxx.woople.com
2. Select account manager
3. Click add user button
4. Enter user’s name, press tab.
5. Enter user’s email address
6. Add user’s password
7. Click add user
8. The Spinny circle spins for thirty seconds or more!
9. While spinny circle spins, I open a new tab on my browser
10. Log out and log in to the same woople account again
11. Select account manager, add a new user, and the spinny thing happens again
12. Close the second tab
13. I go back to the first site and refresh the page
14. Go back to user list, still no user
15. Click add user
16. Enter user details again. Still no luck
17. Select Content Manager
18. Select Account Manager
19. User appears on the list

Ahhhhhh, lightbulb.

So using this list, I can do a few things:

• First of all, I can retrace your footsteps step-by-step, and hopefully, come to the same result that you did (no user in the list).
• Second, I can identify a step you took that might give me a hint as to where the problem is (selecting content manager and coming back).
• Third, I identify problem steps that we might want to avoid in the future (multiple tabs logged into the same account).
• Notice how I used a list to extoll the virtues of a list.

And the best part is, when something weird happens, you can start a list, and go step by step through the process and describe everything you click and everything that happens as you do it. You won’t have to worry about writing a story from your memory twenty minutes after you see the bug.

Thanks for taking the time to read this message. I mean this when I say it: I appreciate every bug you find, and all the time it takes for you to describe them to me. I know how much work it takes (trust me I spend most of my waking hours doing this on our staging environment). It’s tough, detailed, confusing work that makes you focus your mind like a college exam. It’s not fun. But it’s how we make our living, and it’s worth every mind-numbing second. Because when we squash a nasty bug that was hard to reproduce, and savour the moment of knowing it will never, ever come back to haunt us, it makes all those lists and all those steps worthwhile.

With undying admiration,

Yours truly,

Max Cameron, The Bug Hunter

Want to leave a comment? Join the conversation (and vote this article up) on hacker news.

Wed 14 Apr
2010

Blog Reset

Posted at 3:30 PM by Max Cameron Ranting

I'm back from my blogging leave of absence.

I haven't been talking very much on the blog for the past couple of months, in fact I haven't posted anything since January. That's because we've been busy building a product. It also feels like so much has happened since I last posted anything that any attempt to explain what we've been up to would be a drop in the bucket of what needs to be said.

So much time has passed and so much has happened that I was actually scared of writing. What could I possibly say? So I'm going to make things easy on myself (and you) by providing an abridged list of important events to get everyone up to speed. Once this list is published, we'll be up to speed and I will be able to write guilt free.

Jan 6th: Wrote our last blog post. Had coffee with Don Tapscott. That was awesome.

Jan 25th: Chris's first day at Big Bang. Chris deserves a whole blog post written about him.

Jan 24th-28th: I went to Vancouver to sell our software to a bunch of Canadian car dealers. Very surreal.

Feb 3rd-5th: Cameron and Chris went to Chattanooga to introduce Chris to the rest of the team.

Feb 22nd-25th: I travelled to Edmonton, Calgary and Toronto selling software to Canadian car dealers. Still. Very. Surreal.

Feb 27th-28th: Cameron and I worked all weekend preparing for a big business trip.

March 1st-2nd: Cameron and I travelled to Chicago for a scratch-n-sniff meeting with a giant American corporation and our partners from Tennessee.

March 3rd: Started looking at new office spaces.

March 16th-19th: Cameron and I went to Tennessee for our second meeting with the giant American corporation. It went well. The weather was getting better.

April 2nd: Big Bang mugs arrived in the mail.

April 13th: Had our book keeper over to the office and figured out our finances. I suggest you all do the same once in a while.

OK. So there you go. Now I can write about more awesomeness. If you have any questions about the above list, or if there's something you'd like to see me write about, let me know on twitter and I'd be happy to oblige if it sounds interesting.

Sun 07 Mar
2010

Installation, Configuration, Deployment: node.js Applications on Media Temple

Posted at 11:08 AM by Cameron Westland Tutorials

I'm very excited about node.js. I'm sure if you're a javascript fan that you've heard about it too. I'll leave determining the usefulness of node to you. This article serves as a guide to installing, configuring, and deploying node.js on a media temple dedicated virtual server. Even without a Media Temple (dv) you should be able follow along on your own server.

Prerequisites

• Developer Tools
• Root Access
• SSH Access
• Git
• A custom virtual host for your application created in Plesk

Install application

I'm not going to list every step in detail here. This article assumes basic knowledge of FTP or git. I checkout my application to /var/www/vhosts/:virtual_host/application.

We're going to set up supervisor to pipe stdout and stderr to seperate log files. We need to make sure we've created the appropriate log directories before we do that though. Replace :virtual_host with the host you've created.

We also need a startup script so that supervisor can start up our application.

Now we're ready to configure our node server and make sure that it's reliably running.

Install node.js

1. SSH into machine with root access.
2. Create a source folder, download, install, and compile node.

Testing the application

At this point, you should be able to run the node binary and test your application.

Deployment Configuration

I use supervisor for managing the node process. The easiest way to install it is by using the pythong setup tools package.

Install setup tools

Now that setup tools is installed, supervisor is very easy to setup.

Configure supervisor

The manual for supervisor is very straightforward. We create a configuration file. Specifiy our application in the configuration. And set supervisord to start automaticaly.

Test out supervisor by launching supervisord. You can check the status of your application by launching supervisorctl. See the manual for more options. We can now manually start up supervisor so it launches (with our application) on startup. This is useful in the event that your server gets rebooted. To do this, we create an init script:

Now supervisor will start when the server boots up.

Apache Configuration

The last step is to configure Apache to route non-static requests over to node:

Restart the apache process by typing /etc/init.d/http restart and test your server! Viola!

If you have problems with any of these steps or any questsions feel free to @camwest on twitter.

Wed 06 Jan
2010

Building Software is Like…

Posted at 6:45 PM by Max Cameron Startup 101

I once read that building software is like jumping off a cliff and building a parachute on the way down. It stuck with me immediately. It's my stock answer for when someone asks me what I do for a living. I use it because I love the idea. It's funny, and it speaks to the creativity and pressure involved in our field.

But this expression isn't perfect - it ignores another ugly side of software development altogether. And that is finding the patience required to overcome the anxiety of anticipating whatever is about to be completed next.

Here's how it plays out in my head.

James: "I want to build that next feature so bad. This feature will change the world of software."

Bill: "Totally. But, we should probably make it so they can sign in before we do that, right?"

James: "Shit. Yeah, let's do that first. But after that, we are building this feature."

Bill: "But our users need to be able to reset their password, don't they? And the css is pretty shitty James. The sign up page is only a proof of concept."

James: "I should have thought of that. Yeah I guess so… but then we build it."

Sally: "James. I think I found a bug. Whoa, yup this form is seriously f*cked over here.."

The truth just sits there, staring at you like a big turd: Building an application takes a long time. Building software properly takes even longer. Actually testing what you built takes even longer than that.

Priorities change, it's a fact. They change for a lot of reasons, mostly because customers make demands. And they have a right to do so. But we are addicted to the idea of having more and more features. As if the concept of "enough features" even exists. Some place feature lists side by side when choosing a vendor. Mine is bigger than yours buddy.

There is a balance. Our goal as software developers is often to reach a "critical state" of maturity where we've met the "mandatory feature set" in our respective niche markets and can begin to differentiate ourselves from our peers with our unique features.

The funny, if not ironic, part of this story is that we're probably building faster than anyone has built before, with less resources. In the past, it probably would have taken ten times the personnel and ten times longer to build as much as we have. Yet the feeling remains.

It comes back to this; I can't wait to build the next feature. It seems less and less likely that we'll ever get there. And that's because there are never enough features. There is never enough refinement. There are never enough answers to enough questions.

So here's an alternate take on the classic.

Building software is like sailing around the world. But you leave on a raft, and every day you get not enough wood to build the next piece of what will become a boat that can take you across the sea.

And there's pirates.

Mon 14 Dec
2009

Now hiring: Junior Web Developer

Posted at 2:45 PM by Max Cameron Community

We're looking for a Junior Web Developer to work at our office in Toronto. This position starts as a six-month full-time contract with the possibility of extension.

You'll be responsible for:

• Creating at least one brand new website this year
• Auditing, maintaining and improving an existing family of websites
• Implementing web-based marketing efforts

We're looking for someone who:

• Can engage clients over the phone and in person
• Works productively and efficiently
• Who understands the process involved in creating a website from start to finish
• Is prepared to defend their opinions and can handle honest feedback
• Aspires to have a career in this profession
• Is pragmatic in their approach to web development and standards
• Has experience on the Mac platform
• Has a desire to continuously improve and learn

About the Company: Read our blog

Interested? Email max (at) bigbangtechnology.com

Tue 27 Oct
2009

RFPs Will Kill Us All

Posted at 2:34 PM by Max Cameron Startup 101

Creative Exploitation and Speculative Work in the Context of the Client-Vendor Relationship

What is an RFP?

An RFP is a document that a company (the Client) makes and publicizes when it wants to get something built. Lots of other companies (the Vendors) make detailed plans about how they would do the job, and the Client gets to choose which Vendor they want to hire for the job. In this case, we're talking about building websites and software, although RFPs traditionally were used for procuring goods, rather than services.

RFPs and the American Dream

For a Vendor, an RFP can look appealing and desirable. It's a chance to compete with your peers, and an opportunity to bid on a piece of work that could be very lucrative. It's a lot of work, but when it pays off, it can be really sweet. Winning one big RFP can get the ball rolling for a new company and establish a reputation for success. It's sort of like the American Dream: if you work hard enough, anyone can make it to the top. If you sweat and bleed enough while making your RFP, there's no telling what account you can land.

For a Client, an RFP is an all-around good deal. Lots of companies jump at the opportunity of landing a big account, and Clients get lots of Vendors to choose from. They even get a range of possible solutions to their problem, and Clients benefit from each and every response they receive. They get to choose the Vendor they work with knowing that the firm they chose has an undeniable advantage over their competitors. Finally, Clients are afraid of getting ripped off, and "shopping around" using the RFP process ensures that the Client is getting the best deal.

Exploitation and the RFP System

We do not respond to RFPs, and we think the world would be a better place if our peer companies made the same decision. Here's why:

Writing an RFPs is based on the assumption that the Client knows what they want, and how they want their problem solved. Clients end up trying to solve problems outside of their domain, where they are less effective. Therefore, the sense of protection an RFP is supposed to give the client is actually an illusion. It doesn't matter how well a firm implements the wrong solution to the wrong problem.

Responding to RFPs takes a long time and a lot of resources to do properly. When a Vendor takes the time to respond to a new RFP, who pays for that time? The answer is that an existing Client pays for it. Wouldn't those resources be better spent on providing better service? Wouldn't providing better service lead to more referrals? Wouldn't more referrals reduce the need to apply for RFPs? Doesn't that mean that responding to RFPs is similar to ripping off your existing clients? (Carl from nGen Works wrote about this recently).

There is a commonly-accepted belief among Clients that Vendors should work for free. This sense of entitlement exists because we as Vendors propagate a mismanaged Client expectation. The reason some Clients frown upon the concept of wireframes and iterative design is because we as Vendors give them reason to do so. We give away production-quality work for free. No wonder people think what we do is easy. We make ourselves look cheap.

Clients benefit from work they do not pay for. If a small Vendor responds to an RFP with an amazing creative idea, there's nothing stopping the Client from hiring a different agency (or worse - building the project in house) and handing over the small Vendor's great idea as "inspiration." That's just cruel, and it happens all the time.

Responding to RFPs is not democratic. Vendors with the biggest portfolios and the most money to spend on the RFP are generally those who win the new business. Ironically, the Vendors with the biggest markup (in order to spend more on RFPs), and the worst value proposition, are the ones that are rewarded with new business. The Client who thinks they have scored the best deal because of the prettiest RFP is actually suckered into paying more so the Vendor can respond to the next RFP. It's a cycle of ripping people off.

Emerging from the Dark Ages

The alternative to the RFP process starts with us, the Vendors.

We must stop responding to them. We must stop taking money from our Clients to respond to RFPs. We must take that money and provide better service to the Clients that trusted us in the first place. We must find a better way to ensure Clients are actually spending their money wisely and getting good value. We must hold ourselves to standards. We must belong to standards-based organizations that guarantee we are offering quality service and value.

Clients can help too.

Clients should understand that the RFP process does not work for buying services like it works for buying goods. They should stop putting out RFPs altogether for services. They should start building relationships with the Vendors who provide the most value. They should also maintain staff members who have the ability to properly evaluate different Vendors. Once they have found a Vendor who they trust, they should allow that Vendor to participate in defining the problem to be solved, as well as the solution to that problem.

In this ideal case, the Client pays less for a better service. They solve the problem that actually needs to be solved, and they'll learn that working with small Vendors can actually be a strength, and not a weakness.

DISCLAIMER: This article was not written out of spite or bitterness. We have not recently lost a bid on an RFP. We've never responded to a public RFP.

Are you upset we don't have comments? Don't worry, you can join a really great conversation on hackernews.

Wed 23 Sep
2009

The Art of the Referral

Posted at 6:08 PM by Max Cameron Startup 101

How to lose a win-win situation.

Referrals are crucial to all of us

From what I've learned in the past year or so, referrals are the lifeblood of our industry. But for a small shop, they're more than lifeblood; referrals make the world go round. Traditional promotional strategies are becoming irrelevant, but the need to promote ourselves remains as strong as it ever has.

Advertising has become impotent for two reasons: the printing press is now free, and the markets have changed as described in the cluetrain manifesto. Tactless salesmen are exposed as smiling bastards, commercials are easily ignored, and ads seem to be status symbols at best. When was the last time you bought something from an infomercial? Would you ever start a direct mail campaign to sell your latest product?

Job recruiters (HR is another important goal of promotion) are frequently ridiculed and held with contempt for their impersonal pursuit of "human capital." And direct solicitation of new business reinforces our reckless delusion of speculative work and RFP's.

True power lies, as many people now know, in the opinions of your neighbours and in your trusted friends. The battle for hearts and minds is no longer a matter of achieving more and bigger, but rather in achieving better results with less. And a referral is simply the word-of-mouth equivalent of a viral marketing campaign.

Referrals and Collaboration

An active network of referrals is allowing a new decentralized network of small businesses to thrive, collaborate, and compete with companies that would otherwise stand unchallenged. And this network of referrals is allowing a new generation of leaders to emerge, because building relationships requires trust and affects reputation.

A referral can come in many forms; a letter of recommendation or testimonial, a link on a blog or a few kind words on the phone. This article talks about another type; a more active orchestrated connection of two parties who would mutually benefit from each other's proposition. These are the times when someone you respect calls you up asking if you can take on a job, or if you know someone who can. These are the best referrals if they go right, but they're the worst if they go wrong.

The Best Laid Plans

And sadly, a disaster like that can happen all too easily, and make you wish you never tried to help in the first place. Think of the time you thought your buddy Jimmy and your cousin Sally would really hit off. It's an uncomfortable place to be.

Then there's nepotism. Nobody's perfect - it's natural to vouch for your family members or close friends of family. But unfortunately that's where we encounter a lot of,"We can save a killing if we let Tommy's son take care of this website project thing." It's just a symptom of a more profound cause.

"Max - I have this awesome job that has to get done… by end of day tomorrow." If a deadline is dictating who you refer for a job - it's a tempting way to lower your standards for a referral. If you want to be the one to step in, pull out your black book and save the day, make sure the conditions for success are present. The desire to impress can make people act out of desperation, and not of sound guidance.

Another perilous possibility is you refer a great producer with a project that turns out to be terrible. If I start handing out lemons to my friends, eventually they'll start saying no.

What Makes a Good Referral

A good referral happens when the members of the agreement are united as trusted parties. Trusted parties are not the guys you met at barcamp last week. They are people you've worked with productively and who display a high level of professionalism in their work. Trusted parties can legitimately vouch for each other because they've connected with them on other projects.

So if I'm asked to provide a referral, and if I can think of the right person for the job, I can say, "Sure, this is John. I've worked with him before on a twelve week project. This is how good John is, this is what it was like to work with him, and these are the results he achieved.

When you can pull something like this off, you develop a reputation for helping people. When you refer someone and the project is successful, you trust the person you refer more, and your network of small technology companies start to work together. When one company is overwhelmed, they can turn to another trusted party to serve the needs of the customers that would otherwise go unanswered.

When large projects emerge, the small companies that trust each other can collaborate on projects that would usually be off limits. Good referrals are good for the community, when everybody holds up to their end of the bargain.

Good referrals take time and effort to facilitate. It's important to actually understand the nature of the project, and make sure the right people have the time to do the job right. It's not enough to refer someone you think you know, it's imperative to understand who you're referring to what.

Consequences

The consequences of failure can be costly, embarrassing, and demanding. Success, on the other hand, enables entire communities to thrive. Referrals allow leaders to emerge, and those leaders can accomplish greater feats together than competing apart.

It's easy to make a bad referral, and we should all strive to devote awareness to managing the relationships we orchestrate. If we treat our referrals like we do our own jobs, we can do our part to enrich the communities we belong to.

Wed 19 Aug
2009

The New Start Ups

Posted at 3:36 PM by Max Cameron Startup 101

We don't want to be Microsoft, and we sure as hell don't want to be Facebook. We want to be the guys that you can talk to, the guys who are quietly creating excellent software for the long tail, and doing it our own way.

It feels like there's a new wave of technology start ups making a run of it these days. Long-passed are the days that disgruntled business analysts throw their arms in the air, declaring they will control the future of desktop computing. I have an archetype in my imagination of a suit screaming "We're going to get us some VC, build a mamoth engineering team, lease a huge office in silicon valley, and acquire Yahoo by 2011!"

The New Start Ups are small teams with interdisciplinary skills, who are not bound by old production or management conventions. These teams are less than five people, usually pairing an engineer with a history graduate, or a client lead with a support expert. This type of mixing and matching of skills and world views is making applications simpler, and more human.

These companies have never seen a Gantt chart, and they never plan more than six weeks of their next release. These companies know that gathering up front requirements and planning a whole project based on a massive matrix of assumptions is a waste of time, money, and sanity. In other words, we don't chase windmills. A software application has a life of its own, a life that is only discovered when it starts to take its first steps.

These companies are support-heavy. They'll literally do anything they can to actively communicate with anyone willing to use their product. They scour their analytics and visit every site that links to them. They check their twitter every morning and reply to every mention as soon as they can. They understand that respect comes from support, because they're also stuck arguing with cell phone providers as much as anyone else, and losing just like everyone else.

These firms are frugal and averse to debt. VC funding almost certainly dooms your product to scope creep and mediocrity, bank loans are the chains that tie you to the ball what was once known as a "business plan," and the only angelic aspect of an investor is that they shoot arrows when they think they're helping. The New Start Ups are therefore finding ways to sustain their independence.

The New Start Ups have replaced business plans with release plans, and have offered simple, if not humble solutions solving one problem at a time. They know that 80% of features are never used, and exist mostly because of the bizarre requirements documents created by stick-holders… I mean stake-holders.

The goal isn't to become the next conglomerate, the next acquisition, or the next poster boy. The goal is to work hard, fly under the radar, and quietly change the way software is made and delivered. Their goal is to listen to customers, always to respond, and above all else to use their own intelligence to make effective decisions which must always result in a simpler solution than existed before.

Marketing is in a transformation. I think this is because marketing as we knew is the dead elephant in the room, and it stinks. Marketing budgets are now being used to build better software, because good software should speak for itself. Customer support is another form of the new marketing. And this is a great opportunity because the big fish have done such a terrible job at taking care of the people that guarantee their existence.

The software they're making is changing too. Less features, better features, and simpler features is today's rallying cry. Let's not solve the world's problems when we only need to solve one of them. And while we're at it, we don't need to solve everyone's problem, we can solve one problem for one group of people and make a pretty nifty living while we're at it. The products are stripped down, minimal, and void of clutter. The audience is some of us, not all of us.

And all of this works because we don't want to be Microsoft, and we sure as sure as hell don't want to be Facebook. We want to be the guys that you can talk to, the guys who are quietly creating excellent software for the long tail, and doing it our own way.

Thu 13 Aug
2009

How Balsamiq Mockups is Inspiring our Start Up

Posted at 10:14 AM by Max Cameron Project Management, Startup 101

Who knew an application this simple could affect us so much. This is my review of Mockups by Balsamiq.

About two months ago, I wrote to Valerie at Balsamiq, and asked for a product licence for an app I started hearing a lot about, called Mockups. Mockups is a lightweight tool for designing wireframes; the blueprints we make before constructing an application. In return for the licence, I agreed to write an honest, objective review.

When I finally felt I had used the app enough to write something decent, I spent nearly an hour digesting the Balsamiq website, which is refreshingly full of information, and not just copy. What I discovered is that the characteristics that make Mockups outstanding are reflected in the company that makes it. This is software for the people, by the people.

I'm not a programmer. But because I run a technology start up, I find myself responsible for fulfilling many roles. And this is the amazing thing about Mockups: it allowed me to find my voice in the process of developing software, and to take an active role in the interaction, information, and user experience design of the application we're building. Before Mockups, I could suggest changes and provide verbal feedback. After Mockups, I could contribute in a much more meaningful way. It gave me the power to articulate my thoughts and bring them to life. You can't get a much better review than that.

Mockups works because it's simple. It is the most advanced yet acceptable solution to the problem: It is too difficult and complex to create agile wireframes for designing applications. I had experimented with different apps with more advanced feature sets, and I didn't get as much out of them as I get out of Mockups. I see a trend in the best software and applications being used today: build less, build simpler, and build better: Mockups is a perfect example of this trend in action.

I'll go even further and say that Mockups influences the software we make. This is because the flexibility that this tool gives us allows us to iterate more often, and receive more feedback faster. Integrating Mockups into our design process is improving our ideas, and therefore improving the software we produce. Mockups is, in my opinion, the most agile wireframe software I've seen, and by that I mean it facilitates agility inside our company.

Instead of doing a full break-down of all of the features inside Mockups, I'd prefer to send you to their website, which does a much better job explaining what it does. But I will mention that its integration with Dropbox is a delighting feature, which allows us to collaborate across wireframes in near real-time. I look forward to their web-based release of the software, which I'm sure will stir more than a few feathers.

And here's the icing on the cake: Balsamiq as a company is inspiring us to pursue our dreams. They are proving that a small, independent company can sell an amazing product successfully, while maintaining their core values, staying small, being green, and not trying to take over the world. But I think they will end up dominating this space, in spite of their humility.

So, from Big Bang to Balsamiq, you have our full support. We love your product, we use it all the time, and we consistently recommend it to anyone working in our industry. It is changing and improving the way we and our peers develop software, and for that you should be commended over and over again. Keep up the great work, we look forward to seeing what you have in store for us next.

Fri 07 Aug
2009

The Critical Period of Software

Posted at 11:13 AM by Max Cameron Project Management

The first release is a real challenge, is it not? It's the hardest to estimate, the hardest to construct, and perplexing decisions await you at every turn. To complicate matters further, when you're kicking off a multi-release project, clients want to go big right away. They're are hungry for a four course meal when you're delivering an appetizer. But it's important to help clients understand why the first release is the most precious, even though it may deliver far fewer features than subsequent releases.

The way I see it, the earlier a decision is made, the more significant and influential it is on the project as a whole. We should pay special attention to the decisions we make first, because they will not only define the outcomes of the project, but they will constrain future inputs (options to be considered when making future decisions) as well. Therefore, we should move slowly and methodically in the beginning, although the tendency is to feel urged to rush into a project because the initial momentum is so great.

From what I read, babies can recognize more than 3,000 words by the time they are 2. Some theorists argue that a person's identity is well established by the time they turn 7. It becomes exponentially harder to learn a language, play an instrument or pick up a sport after puberty begins at around age 12. In human psychology, a lot of complex things get figured out relatively early on. These ideas are generally encompassed in the Critical Period Theory.

Things that are cemented during this critical period, tend not to change. You don't just forget your first language, because it gets hard wired into your brain. That also means we tend to take these critical aspects for granted. Additionally, the fact that you learned English constrains the options you have going forward. Therefore, it's more important that you learn a language than what you end up doing with your ability to speak, read and write.

The same pattern holds true for software development. When you choose a framework or programming language to develop the application, you're constraining the options you have to work with. And we shouldn't forget that's a good thing. But the same holds true for feature development. There is no all-encompassing documentation predicting the content of an application, the decisions you make first end up being the most important ones. The constraints you establish first will shape the path the application will take on its way to maturity.

So, when you feel the need to reassure your client and maintain the trust you've worked hard to achieve, remind them that three features which lead us into a flexible and integrated future far outweigh the five that lead us into the layered control of haphazard construction.

Tue 04 Aug
2009

Links of the Week 3

Posted at 5:32 PM by Cameron Westland

Instead of posting links the minute I find them, I've started holding on to them for a week and then blasting you with them if they still hold my interested by the end of the week.

An Easy Way to Increase Creativity

Application Submission Feedback

A nice collection of feedback from developers. Here's hoping to finding a consitent pattern for app store rejection.

Chroma-Hash

An interesting way to visualize your password and confirm password boxes.

Embrace technical debt

I'm having a hard time embracing financial debt. I'm not likely to jump on this bandwagon anytime soon.

Startup company uses flawed software-development contract with outside consultant, ends up having to go to court to stay alive

Use good contracts.

Anatomy of a feature

While I'm no longer a huge fan of NetNewsWire, any help to explain why feature-development is hard is appreciated.

The Secret of Monkey Island: Special Edition Evolution of Guybrush Shirt

I want this.

Seth Godin on why marketing is too important to be left to the marketing department

I'm watching this right now.

Fitnesse and xUnit, the perfect TDD marriage

Tue 28 Jul
2009

Links of the Week 2

Posted at 9:55 PM by Cameron Westland

Instead of posting links the minute I find them, I've started holding on to them for a week and then blasting you with them if they still hold my interested by the end of the week.

Everday Innovations - bookmarker

Ergonomic Pen, Flag Dispenser, Bookmark, Book strap. I want this.

Ruby Reports Book

When we start to build reporting features, you can be sure we'll be looking at something like this instead of rolling our own.

Lockdown with Authlogic

Don't try to write authorization features yourself. We're currently evaluating both Lockdown and acl9.

The Pushbutton Web: Realtime Becomes Real

Anil Dash provides probably the best description of this emerging paradigm. We talked about leveraging this to get GitHub and Lighthouse communicating.

Make your test suite UNCOMFORTABLY FAST!

Apparently this works with multi-core processors. Anything that makes tests run faster is OK by me.

alivepdf

Client side AS3 PDF generation library for Flash/Flex/AIR.

Bacteria make computers look like pocket calculators

Funny, I've just started learning about the Hamiltonian path problem in Introduction to Algorithms.

Economics in One Lesson

It's literally once sentence to learn and a lifetime to understand.

Fri 24 Jul
2009

Software is a Journey

Posted at 1:01 PM by Max Cameron Startup 101

Two guys, one laptop, and 4636 kilometres of pure Canadian coding. This is the Cross Country Coding Tour 09.

The Dilemma

As the rain whips against the windows of our home-office, Cameron is sitting at his desk behind me, coding a new component for the application we started building in June. It's the type of day I wish I had a proper desk lamp, because our overhead lighting is insufficient, and working too long in the dark pinches the back of my eyes. It's one of those days where I wish we could be working from somewhere else.

We've been on a bit of a journey lately, building our first product as a pair. It's exciting and terrifying, especially since we're in the midst of our first release. I don't expect it to get much easier, but believing it will is a comforting illusion. Since I'm a manager, and Cameron's a programmer, my job is to do whatever it takes to let Cameron sink deep into writing code. When I'm not busy doing that, I'm by his side, getting him to think out loud, asking questions and making small contributions when I can.

It's an intense process. There's a lot of disciplines getting thrown together, and the most challenging obstacles are invisible and masked in subtlety. Most of the time, those challenges are only resolved when a new perspective emerges. A new perspective, a different angle, a change of scenery.

The Opportunity

And as luck would have it, my parents told me they would love it if I could drive their car from Seattle, where they live, to Toronto. No can do, I thought, too much work going on. And while the idea was unappealing at first, after a while it crept back into my head. I've always wanted to see more of Canada. The more I thought about it, the more I realized it could actually be possible. Eventually, the thought became a dream and the dream became hard to shake. So we talked about it and decided to do something about it. And so was born the Cross Country Coding Tour 09.

The Rules

It's all about the code, so while I'm driving, Cameron will be right beside me working from the passenger seat. It'll be just like working in the office, except the office will be moving rapidly across Canada. Cameron will be working on his local machine, and we'll check in our code every night from wherever we find ourselves staying. I might have to take care of my QA during our down time, but that's a sacrifice I'm willing to make. We're going to stop every night so we can rest up, but this is a full time job.

The Route:

The Itinerary

1. YYZ to SEA: One way flight on September the 11th, 2009, from Toronto to Seattle. We'll spend the weekend in Bellevue with my parents, raid my dad's book collection, meet with some of his colleagues, and eat a lot of good food.
2. SEA to YVR: Might as well get the border crossing out of the way sooner rather than later.
3. YVR to YQR: Not sure what's in Regina, but I have a funny cousin named Erin who lives there.
4. YQR to YWG: I love Winnipeg. It's where wild things have been known to happen.
5. YWG to YQT: I hear they have a solid minor league hockey club in Thunderbay.
6. YQT to YYZ: And home sweet home.

I should probably also mention we've applied for a Guinness World Record for most lines of code written while driving in a car. It takes four weeks to find out if they'll endorse the idea, so no promises. I'll keep everyone updated when I hear back.

The Point

We're doing this for a few reasons:

• Perspective: We've already established that your environment affects the artifacts you produce. Our time traveling is going to let us take a step back and reflect on the application as we develop it.
• Constraint: There's nothing like sitting in a volkswagon bug for a week to get some serious work done.
• Experiment: We'll find out if mobile telecommuniting is, in fact, possible.
• Carpe Diem: It's not enough to say, "Maybe one day we can do this." It's now or never, because it'll never get any easier.

The You

If you think what we're doing is cool, and you want to do something to help us out, worry not. Here's how you can lend a hand:

• Place to stay: If you know anyone who lives on our route, and if they might have space to sleep two polite lads who like to cook, put us in touch so we don't have to spend money on run-down motels (although run-down motels are amazing).
• Must sees: If we're going through a place that has an incredible off-the-wall tourist attraction (thirty foot muffin is a good example), unforgettable culinary delight, or fascinating dive-bar, let us know.
• If you know anyone interesting that we could meet up with (Ol' uncle Ricky from Lethbridge woooooo!), we would love to hear from you.
• Otherwise, your best wishes are always welcome as well.

We'll be blogging as much as we can from the road, and we still have plenty of time until we head out west, so stay tuned for updated itineraries, unsubstantiated predictions, and shouts of excitement. Oh and ps - if we can pull this off, so can all of you.

Sat 18 Jul
2009

Links of the Week

Posted at 3:22 PM by Cameron Westland Links

Instead of posting links the minute I find them, I've started holding on to them for a week and then blasting you with them if they still hold my interested by the end of the week.

Integrity Continuous Integration Server

I'm currently evaluating using this on our Rails application. Used by the fine folks at thoughtbot.

FlexMonkey 1.0

I've had my eyes on this tool for a while, it's a little tricky to set up if you're trying to access web application instead of just a swf, but we're exploring using it in conjunction with FlexUnit 4

Richard Feynman: The Messenger Series

I haven't had a chance to watch these yet, but I plan to. Bill Gates personally invested to get make these videos available.

New York Nearest Subway Augmented Reality App

Max and I have some ideas similar to this that we've chatted about briefly. Great to see more applications using the compass in an intelligent way.

Project Code Rush

I really enjoyed this short documentary detailing the final moments of the independent Netscape.

Flash Love Letter Part 1

This essay tries to convince Flash game developers to choose a realistic revenue model other than advertising. I think the principles translate fairly well to software as a service.

Tue 14 Jul
2009

8 Things We Need to Work with an Angel Investor

Posted at 9:09 AM by Max Cameron Startup 101

Everyone wants to go to heaven, but nobody wants to die. A lot of people want angel financing, but it always comes with strings attached. Here's the story of how we came to an understanding with our investor using basic, high-level ground rules as a starting point for negotiations.

When we received an offer from an angel investor for them to finance the development of a product that we would own together, we were skeptical. About a year before the offer, we were hired as sub-contractors building a project for the same investor. Since we were junior members of the team, we weren't empowered to make any decisions. Unfortunately for everyone involved, the old project turned out to be a mess.

Inevitably, we burned out, and the team of contractors disbanded one by one. By the time we concluded it was time to take off, all parties were consumed by mistrust. Building software isn't worth being miserable, and we were ready to give up 80% of our income and eat the red pill. But our investor wasn't ready to give up. He asked us what we would need to stay on board and start again from scratch, in fact he challenged us to give him a reason to walk away.

The least we could do was take a shot at it. Here's the email we sent him a few days later.

Dear Angel,

Thank you for your time today. Here's the list of our needs:

1. We don't want to engage the clients that you maintain (no side projects, marketing sites, or sales meetings).
2. We need to have secure financing, every month, without fail.
3. We need to establish expectations for this product together, and stick to them.
4. We need two stakeholders in this project (Us, and you). Only expert opinions should be considered when evaluating new features.
5. We need to make our own product, and own a fair portion of it.
6. We need to know our operating budget.
7. We need to resource this project as we see fit.
8. We need to trust that these commitments will be honoured.

If we can address these eight needs that we have, there's no reason we shouldn't be able to do work together.

Best,

Max

Turns out he thought our list was pretty reasonable. If anyone's wondering why they haven't seen much of us lately at some of the great conferences and meet-ups, it's because we've been busy working. We're looking forward to getting back out into the community and talking about our new project, just as soon as we release this beta.

Tue 07 Jul
2009

The Meaning of the Small Corporation

Posted at 2:40 PM by Max Cameron Startup 101

A few thoughts on creating a technology start-up, from a guy who understands that it takes discipline and humility to serve and nurture your company into maturity.

When I started Big Bang with Cameron I knew I was going to work hard, I knew I was going to challenge myself, and I knew I was going to go a bit crazy. I didn't know how much it would take to succeed, or what kind of existential crisis it was going to throw me into.

Working for someone else is easier than working for yourself. You get to concentrate on what you know how to do, you know what your purpose is. You have a role within the organization, and you fulfill that role to the best of your ability. If you do your job well, you get a raise. If you don't do your job well, you get fired, unless you're a damn fine bullshitter. Pretty simple.

But when you start a company, you become responsible for creating an environment, a culture, and carving a space in the world for you to occupy and grow out of. In other words, building a company from scratch is a long and terrifying journey, full of opportunities. Opportunities to fail, to succeed, to learn, and to create.

A corporation is both an abstract thought and a tangible entity. As an entity, a corporation is a legally sanctioned association of individuals, which exists independently of its members. But as a concept, I believe a corporation is a prism through which we can channel our creative energy thus producing artifacts which are greater than the sum of their parts.

A corporation isn't something you start to get rich. It's something you shape, nurture, and build. And if you build it well enough, and give it the strength and identity it needs, it will carry itself and its members through unbelievable paths and roads. A corporation has an identity all of its own, an identity that is created through the contributions of its members.

A corporation needs to be served in order to succeed. It demands discipline from its members, and it requires diligence from those who care for it. Discipline means that I get paid a little and work a lot. Diligence means that I have responsibilities to my company that require me to consistently sacrifice in its best interest.

How we're serving our corporation

1. Minimize costs (aka pay yourself as little as possible): Corporations need money to become great. People that enrich themselves at the cost of their company leave their own hands tied. Financial independence (even if it's only enough to keep you going for a month or two) enables you to stand up for what you believe in, say no to bad clients, avoid developing banner ads, even let you build that product you've been dreaming of.
2. Experiment and fail quickly: Building a corporation in this sense is like cultivating a garden. You nurture the good plants, and remove the weeds. Take your war chest, and put it towards many, small experiments. Let them fail, and let them fail quickly. The worst regrets are the risks you refuse to take.
3. Invest in your environment: A corporation is nothing without a great environment to create in. Buy as few things as you can, but when you do buy a necessary item, buy the best. This includes designing the best workshop, hiring the best lawyers and accountants, and taking the time to eat right and exercise. Your environment feeds back into your practice, and defines what you create.
4. Educate your members: Educating yourself is not a luxury left to established firms. Education gives you the power of knowing the practical and theoretical context you need to build something relevant. It could be reading books, going back to school, or talking to your mentors. Do it before work, after work, or during your lunch break. The day we believe that we are educated enough, is the day we fool ourselves into accepting mediocrity as an acceptable standard.
5. Take care of your members: Whether it means taking out insurance, contributing to medical or educational expenses, allowing for time off, or simply being a good friend to the people you work with, always try and be a source of strength for your colleagues. The big secret is that nobody has all the answers, and we all feel the same stress.
6. Push yourselves: The members of your company need to become better to survive. Whether you're a PM or a Coder, insist that everyone you work with become smarter. Force yourselves to accept the challenge of producing professional artifacts. Don't settle for doing the least acceptable amount of work, and don't be afraid to point out your colleagues' greatest weaknesses. Think about it, and acknowledge you have the opportunity to produce the most amazing work you've ever imagined every time you sit down at your desk.

The big point is, we don't think we'll ever become great if our attitude is "What can my company do for me." It's not about money, it's not about prestige, and it's not about only doing the work you want to do. It's about capitalizing on the fact that humans can accomplish marvelous feats. If we're going to build the company I know we can build, we're going to get our hands dirty. We're going to work for little pay, and we're going to ensure that we're strong enough to do what we know is right.

Mon 22 Jun
2009

Tools for Event Organization

Posted at 10:06 AM by Justin Kozuch Community

As an event designer, I use a number of tools to help organize and execute various events in the tech/web community. While I won't be able to talk about all of them today, I'd like to focus on a few that I REALLY like.

Organization

I've used a number of organizational tools to manage the event design process. One tool that I love to use the most is Things ($49.95 USD), developed by Cultured Code.

One of the great things about, well, Things is that it allows me to breakdown different events into projects, and within those projects I can create tasks related to that specific event. I can track ticket sales leads, sponsorship information, or any other type of content. One thing it doesn't do is allow for the importing of documents (Word, PDF, etc) or store information in the cloud. Fortunately, CulturedCode created a slick iPhone app ($9.99 USD) that syncs your data across your iPhone and laptop/desktop. I have no real complaints about Things at all, except for the lack of the document importing/cloud data storage functionality.

Another application that I like to use is Evernote (free, with the option to upgrade to a paid account) to store data like attendee registration lists, catering information or anything that is relevant to the day-of. Evernote is a great tool, because not only can you store content on your phone (iPhone, Palm Pre, Blackberry, Windows Mobile), it syncs your data into the cloud and into the software application. As if that isn't enough, there's also a web-clipper extension for Firefox and a USB key version of Evernote.

The free account only allows you to store 40MB of data, while the premium account ($5/month or $45/year USD) allows you to store 500MB of data. Check out http://www.evernote.com/about/premium/ for more information.

Wrap-up

Post-event engagement is an important part of the process that some event organizers neglect. Understanding what your attendees thought of your event is critical to learning how you can improve future events. I've setup a Google Docs form to get feedback from event attendees to gain insight on what they thought of the event, the speaker, and the content. I like to ask attendees what they would improve, as it gives them a sense of ownership.

Which tools do you use to organize and curate events? What tools or services do you use for post-event engagement? I'd be curious to hear your thoughts! Hit me up on Twitter.

Tue 09 Jun
2009

Four Questions for a Technology Start-Up

Posted at 6:27 PM by Max Cameron Startup 101

Here are four questions that have been agitating me lately. They're not meant to be insurmountably philosophical or life-changing. They're more like nerd pick-up lines. Some have said that four is an arbitrary number, and it is. I feel however, that an even five would fit no better. Hopefully they'll put your craft into perspective and show you how many more questions we have yet to answer.

If there was no internet (gasp), what sort of things would you design?

Would you be inventing a new solar panel or a shaping a mahogany table? Would it even be an object? Perhaps you would be molding a process or a policy? Creating analogies which contain your virtuous characteristics can help you reflect on the digital tools or processes that you're developing now.

If your company was a country, what kind of government would it have?

How would your government make decisions? How would it protect itself and its identify? Processes, pay scales, conflict resolution, and purpose are all derived from the same values which define a government. Would you be a Scandinavian vision of democracy? Or would you be like a well intentioned dictator? I like to think that we try and incorporate different elements of different political theories, so we should be flexible. Let's not forget as well that revolutions happen as well.

If you could spend 10,000 hours becoming an expert on one thing, what would it be?

The question du-jour at the office these days. We all want to be experts. Rumour has it that becoming an expert takes ten thousand hours of practice. How can you find out what you want to focus on for such a large amount of time, and how do you go about doing it. Sometimes I think life would be easier if I wanted to be an expert in something simple, like pizza for example. As of today, I haven't identified my 10,000 hour goal. It's just a matter of time though, because it can't hide forever.

What are you not willing to do for success?

Here's a tricky one. There's a lot of ways to make a buck out there. Every single one of them is challenging. And only some of them take you where you want to end up. Choose wisely, and never worry about next month's rent.

Tue 02 Jun
2009

Community Building 101: Some Thoughts

Posted at 8:11 AM by Justin Kozuch Community

Traditionally a "community" has been defined as a group of interacting people living in a common location. Currently there are dozens of different types of communities, and even many more definitions of what "community" really is. I'd like to post some thoughts on community building, as it is the core of what Refresh has set out to do; build a community and promote it.

If you are responsible for building a community, I'd like to offer you some advice. You don't have to take it, you can throw it away and ignore it if you like. It comes with no strings attached, and I won't be offended.

But if you are serious about building your community, please pay attention because it makes the difference between having advocates and having people not take you seriously.

If your users engage, engage back.

There's nothing more disconcerting than to engage a community builder into a question, only to be completely ignored. Community builders, there's a very good reason why your email client and why Twitter includes a reply button. USE IT! It's free, it takes only a few seconds and you'll feel alot better. And most importantly, you're building a 1-1 relationship with that person that can later translate into offline interaction, which means sales, advocacy, love and more.

Rule of thumb? It's about the people, stupid.

There's no such thing as conflict of interest in community building.

Like the saying goes, if I had a nickel for every time I heard someone use "conflict of interest" in the same sentence as community building, I could have retired years ago. If people want to help you build your community, citing "conflict of interest" is an irresponsible way of refusing said help. A great example of not citing conflict of interest was the #hohoto event that took place last Christmas. Each person involved in the planning brought different skills (maybe some brought the same) to the table, and many more brought their ideas and suggestions. But not once did they ever say no or dismiss any idea. The result? A packed house, an amazing crowd, and they raised over $25,000 for the Daily Bread Food Bank. All that was done in 13 days.

Rule of thumb? Don't say no. Ask for feedback/opinions/assistance, and your users will do more for you than you ever expected.

If you're a community builder, you're in the public eye.

I don't really need to explain why this is important, but I will anyways because so many community builders forget this very important rule. If you are going to address an issue on a blog post, a forum, Twitter, or any other medium, know that 1) Google will find it, and 2) People will talk about it, retweet it, call you out, expose you and make you sorry you were ever born. People today have finely tuned BS receptors and amazing research skills. They will use both to their advantage. Remember that before you hit the submit button on that blog comment.

Rule of thumb? Watch what you say. The past always comes back to bite you.

We asked this question of our Twitter followers: What are the characteristics of a "good community builder"? The responses we got were very interesting:

Kevin Richard: "non restrictive, disclosure (no false pretenses), facilitating rather than forcing conversation, interactive" and "basically not being a corp. shell. The manager listens and responds to the users instead of just pushing out info."

Darius Bashar: "they must be authentic, and have a lot of LOVE. They must also be anti-ROI minded.", and "It is about relationships and about truly listening to your users!"

Dan Codesta: "A good community builder is one who sees an opportunity to fill a need until time comes to 'hand it up' to more capable hands."

Aidan Nulman pointed us to a blog posting about community organizing by Ryan Holiday. It got us thinking: What can we do to make our world better? How can we help our local and global community thrive and be more sustainable? What can we do to help each other succeed, both personally and professionally?

What do you think? What are the characteristics of a good community builder? Hit me up on Twitter, I'd be interested in hearing your thoughts.

Sat 23 May
2009

Community Building 101: Building A Community on Twitter

Posted at 9:00 AM by Justin Kozuch Community

Twitter is a powerful tool for building relationships, if used properly. Used improperly, it can wreak havoc, destroy perception of your brand, and even open you up to litigation.

As a community builder for Refresh Events, I use Twitter almost exclusively (Facebook, LinkedIn, and Google are also part of our toolbox) to reach out to the community and generate awareness of our organization and its events. However for today, I would like to focus on how to use Twitter to build a community.

Is it secret?

Protecting your Twitter updates is akin to telling everyone about your amazing product/service/company, but then introducing a barrier to entry. Seems counter-productive, doesn't it? Imagine if you will someone (let's call him Joe) tweets about how much they love your product. One of Joe's friends, Michael sees his tweet, and is immediately intrigued. When Michael clicks on your name, he is presented with:

Twitter is an excellent tool for building relationships; protecting your updates prevents you from building those relationships and gaining visibility. It also discourages people from following you.

Rule of thumb? Don't protect your updates if you want to build a community on Twitter to complement your offline community.

Sign on the dotted line

Now that you've opened your Twitter account to the world, you'll want to make sure people know you're on Twitter. This doesn't mean you should put your Twitter account on a billboard (unless you have the budget for it!). But you should put your Twitter account on:

• Your website
• Your business card
• Your email signature

Rule of thumb? Twitter is a tool - use it like you would use any other tool to drive awareness, create relationships, and if done correctly, build reputation.

Help me, Obi Wan Kenobi

Many companies use Twitter as a customer contact vehicle. Among these are JetBlue, Comcast and many others (Brands, take note of how they service their customers). I would like to focus on two particular companies and how their use of Twitter has gained them popularity, increased awareness and improved their brand reputation.

I was recently made aware of Hyatt Concierge (hat tip to @jaygoldman), a Twitter-based customer contact account dedicated to helping their customers with hotel reservations, locating tourist attractions, restaurants (outside the hotel, no less), and is monitored 24/7 by Hyatt staff. While this is nothing new, what's unique about their use of Twitter is they don't promote their brand. Instead, they actively support their customers through listening to their questions and providing assistance. Post-sales support is also provided via their Twitter account.

Freshbooks is another example of an amazing company who provides stellar service to their customers through Twitter. They actively listen to their customers, provide support, gather feedback and frequently give back to the community. I recently had a question about their service and within minutes, I received 2 responses from Andrew Peek (@drupeek) and Rayanne Langdon (@rlangdon) with working solutions. Rayanne also made herself available to answer any questions I had by way of a phone call.

Rule of thumb? Make yourself available to people, answer their questions, don't shout about your brand 24/7, and you'll build an army of advocates.

Sharing = caring

Like most people in tech community, I read a number of blogs and RSS feeds. If I read something I feel is interesting, valuable, and important, I have a personal and professional responsibility to share that content with others. Why? Because it shows you're keeping up to date with technology and you're building a reputation as someone who gives back to the community.

That's not to say you should tweet about EVERYTHING you read; doing so will get you unfollowed rather quickly by a large number of people. Instead, pick and choose carefully what you want to share. If you think people in your network would find it relevant to what THEY do (not what you do), it's well written, or it tackles an important business/social/etc issue, I would encourage you to send it out. More often than not, it will fuel discussion between yourself and others.

The wonderful people at RedWire (of whom I am a big fan) do this quite frequently. Their target market is entrepreneurs, and so they often tweet entrepreneur-related content (how to start a business, budget planning, and so on).

Rule of thumb? Share. It's good for your karma, it shows people you care and you never know who you're helping!

Mind your P's and Q's (aka learning how to say "Thanks!")

1. Find some justification for building this feature – write the story.
2. Set up our testing template and review the existing source-code.
3. Write small tests that fail in a logical way.
4. Make the tests pass.
5. Rinse, repeat, until feature is completed.

Legitimize the Feature

Advanced Ticketing Solutions is a Web 2.0 application with gradients, drop-shadows, reflections, AJAX, and more. As a developer on the team, I have been tasked with the job of creating a dynamic filter so that managers can sort through their tickets' priorities without refreshing the page constantly. The server currently polls for the latest tickets every 30 seconds using AJAX and delivers the results via a JSON feed.

Make sure you pop the why stack to make sure that this feature is actually worth implementing. What we come up with is:

As a Manager
I want to be able to filter priorities in realtime
So that I can easily see how many Meltown! level tickets there are without the visual clutter of not-so-urgent tickets

We are going to create a select menu that will sort through a table of these items based on their priorities. The priorities are defined as "Urgent", "More Urgent", and "Meltdown!"

Screencast

Download the Quicktime Version

Fri 27 Mar
2009

Big Bang Technology Presents Freestyle Fridays

Posted at 2:44 PM by Max Cameron Music

I bet you didn't know I could do this!

Wed 25 Mar
2009

Our social network is your social network.

Posted at 4:12 PM by Max Cameron Community

After hearing from Saul Colt at Refresh Events, we decided we couldn't let another minute pass without doing something nice for someone who might need some help.

With My Peoples

On Monday night we had the opportunity to head out to the Center for Social Innovation to attend the latest round of Refresh Events. Justin and Elaine are starting to gain some serious momentum, which was reflected in the attendance and the caliber of participants.

I love Justin, but I’m not going to sugar coat this idea: I could stand to hear a bit less from PR types. It’s ok if you invite them, because we have a responsibility to educate them. But if I have to hear about “The rise of social media” one more time I’m going to laugh out loud.

Social Warhol

I like to dwell on the positive though, so let’s talk about Saul Colt and his idea on what social networking REALLY is. So Saul gets up and lays the smack down and says that pushing a social media strategy on people won’t get you very far. Instead, he says, you have to drop the bullshit and be a nice guy.

Saul says that he spends 80% of his time introducing people to each other. You want to do that? Talk to her. You need this? Talk to him. Let's get you connected. Over and over and over. I like that about Saul, because I like doing the same thing. Introducing two people who need to meet gives me a special feeling.

If you decide to help people, just for the sake of helping them, then they will become your advocates. Basically, you can’t buy love.

Saul correctly pointed out that our most valuable resource will always be our social network. We think he’s absolutely right. He also pointed out that a lot of people are struggling to make ends meet.

It’s funny in a way, because that’s why we made Astroscope in the first place. You can bring a lot of happiness into someone’s life, just by introducing them to stranger. But let’s get back on track, because I do have a message for everyone that we know, and everyone we’ve yet to meet.

I liked what I heard so much that I’m going throw down as well. We’ve been really lucky lately, and when you got it, smoke it (that’s what I always say). So here’s what we have to offer:

If you’re in need, let us know.

Looking for a new job? Let us know. Are you lonely and just broke up with your boyfriend? Let us know. We might not have a perfect solution for you, but if there’s someone we can introduce you to that can help, we won’t hesitate to set something up.

You can reach Cameron or me anytime, any place.

Mon 16 Mar
2009

A Sewer-Clown Stole my iPhone

Posted at 4:40 PM by Max Cameron Ranting

Late Friday night, I was hailing a cab on the edge of a sidewalk, when my iPhone slid out of my hands.

Photo By: mathewingram

What can I say, shit happens.

I’ve dropped my iPhone a number of times over the years, and it’s a surprisingly durable machine. I’ve never managed to break or lose one, which would probably surprise you if you know me personally. I might misplace it, or forget who I lent it to a few minutes ago, but it always ends up back in my pocket.

If I accidentally drop the phone, I always try and place my foot under it to mitigate the impact, and give it a soft landing. This time would be different. This time, because I was standing on the edge of the sidewalk, I couldn’t soften the blow. And it fell, and it fell some more, time standing still while it silently slid through the nighttime air, and I could see very clearly as the bright icons winked at me for the last time.

Photo By: fiomaha

There was neither a clunk, nor a thud. No crash, crack, split or smack.

Just silence.

It took a moment to hit me, but my iPhone had fallen seamlessly between the grates of a sewer, and fell deep enough to muffle any sound it made when it hit the snow or ice below.

I hit a zen moment. I felt numb and free of all consciousness.

Photo By: h.koppdelaney

And then, with all my might, I got down on a knee and I tried to open the sewer grate.

Looking back on it, I realize that it’s probably a good thing that I didn’t get into that sewer on Friday night. I might have injured myself quite seriously, not fully understanding the consequences of that decision at the time. But the point of this story lies outside the boundaries of the existential/metaphysical crisis that is immediately precipitated by the loss of an iPhone.

I’m still discovering and experimenting with the psychological symptoms of iPhone withdrawal. I might write about it someday, after an appropriate amount of reflection. Maybe there’s a lucky sewer clown out there. Maybe he’s got a sweet phone.

Photo By: timboucher.com

Sun 15 Mar
2009

Using Prototype to Inject Custom Class Instances into the DOM

Posted at 1:31 PM by Cameron Westland Tutorials

I've been using the Prototype Javascript Framework more than usual recently to develop some fancy reports for a client. I'm going to share a simple technique that involves using toElement on a class as an easy way to insert it into the DOM.

Requirements

• Prototype Javascript Framework Version >= 1.6
• A reason for building a pure Javascript class.

The Story

A few weeks ago, Max asked me to put his twitter feed on our website. I said no – Twitter does a good job at displaying Twitter content. This got me thinking, however, that other people would want to do the same thing. Also, since Twitter is the new Hello World, this serves as a good example. I've built Max his javascript driven twitter feed. Take a look first, and then we'll talk about what we're doing here.

Getting the Data

After quickly scanning the Twitter API Wiki, I found out that we can use JSONP to load our data. Since we can't directly load the data from Twitter via XMLHttpRequest we have to embed a script tag with the query. Fortunately we can specify a callback function so that when the data is returned, it will fire the function, passing the data loaded from the server to it as an argument.

Once we get the data back we iterate through each of the result items and create a new instance of the Tweet class for each one. We then insert the instance directly into the DOM. As you can see on the sample page the class is magically rendered on the screen. This is because Prototype automatically calls toElement on our class.

What's in the Tweet Class?

This class is very simple. In the constructor it saves the data from the server in instance variables that it will later use in the rendering process (see documentation for details on what gets returned). Next, there is an instance method named toElement. In Prototype, whenever a class instance is passed to any of the insertion methods – Element#insert, Element#update etc. – it looks for this method on the class. Keep in mind that Prototype expects an HTML element or a String to be returned from this instance method.

Recap

• Construct a class passing key information into the constructor
• Maintain a reference to the class manipulating it in memory without worrying about DOM
• Feed it to one of Prototype's element insertion methods just like you would any other HTML element.
• ???
• Profit!

References

• Prototype Website
• Element#insert documentation
• Example Page

Sat 14 Mar
2009

Using the Typographic Principle of Baseline Rhythm to Enhance Website Readibility

Posted at 11:51 AM by Cameron Westland Tutorials

Recent updates to the Big Bang Technology website take advantage of Baseline Rhythm to evenly space text elements and help readability. We hope you like it.

Home Page

Homepage Before & After (hover to see after)

Article Page

Article Before & After (hover to see after)

References & Additional Reading

• Baseline Rhythm Deciphered
• Baseline Rhythm Calculator
• Get Ryhtym in Your Baseline

Thu 12 Mar
2009

Pimp your Twitter

Posted at 9:33 PM by Max Cameron Tutorials

We're poppin a digital collar. If normal twitter is a beat-up oldsmobile with food-stains on the driver's seat and a broken door-handle, our article will take you to a pristine cadillac with suede seats and a nice furry set of dice in the mirror.

When I saw the newest iteration of the fb homepage today, I set my status to something like, “new fb homepage = twitter and the old fb got real sloppy last night and got nasty-busy and then BOOM fb dropped a baby and it looks like twitter’s the babydaddy.”

And then a few of my friends started asking me about twitter. What is it? Isn’t twitter WACK? I said, “What? No YOU wack!”

Photo By: Soul Portrait

Then I came up with a better explanation of what twitter is, which I’m sure they’ve thought of but just aren’t allowed to post:

“Twitter is a giant messy instant message orgy and everyone’s invited.”

So, in honour of that, Cameron and I got together to discuss how we best could advise all our homies on how they can squeeze the most bounce per twitter-ounce.

Lesson One: Learn the streets

Twitter is like fb status updates, except you must remember they are public, and anybody can choose to follow your updates. Of course you can block people if they’re lunatics (or 5/0 ).

If you put an @ right before a username (@maxcameron) for example, and include that in a tweet, that user will see your @tweet, and so will everyone else. This is what I’d call “A shout-out.”

DM stands for direct message. If you put a D before a username in your tweet (d maxcameron), it’s just like a private email to someone.

So now that you know the streets you’re ready for some more advanced pimping.

Referrals from Mr. Tweet: Git at your Homies

This description is straight from the Mr. Tweet website:

Mr. Tweet is your personal networking agent who helps you expand your network easily. To do that, he helps you regularly:

• Get relevant followers by recommending you to them
• Discover great people relevant to your current needs
• Improve your Twitter usage via useful statistics

So all you have to do is follow Mr. Tweet and he starts looking around at your homies and who they dig, and then he looks at which peeps dig your homies in return. Then he says, “why don’t your people and my people get together for a little jammer on the twittosphere?”

There’s other cool features too so check it out.

Desktop client: Because true players don’t sleep

Instead of constantly visiting the twitter website, you can download a “little program” (widget) on your desktop. They’re tight because they nice to look at and don’t get in the way (IE you can hide it from your boss).

We use Twitterific at our office, it has a really nice interface. If you're using windows, you've got a bigger problem than finding a good twitter client. But you can still give twhirl a spin.

Mobile client: RING BLING

Photo By: Urimal

The next crucial step in pimping your twitter is hitting it up on the mobile. That’s no joke. Streetcars, taxi cabs, boring-ass parties, whatever. If you’re at a wedding and you see a drunk bridesmaid fall into a fountain of punch, you need to get that photo out there lickity split you know what I’m sayin?

Check out Tweetie for the iPhone, it’s hands-down the best out there.

Twimailer: Holla at Your Boy Notifications

Usually, when someone starts following you on twitter, you get an email showing you a link to their twitter page. Twimailer seriously ups the pimp-factor by a factor of 3 (easily). When you sign up, Twimailer intercepts the notification emails from twitter, and runs a little background check on the person following you before it sends you the notification.

The twimailer email is hella-pimped-out. It shows you how many people the person is following, how many followers they have, it shows their last ten tweets, it shows their bio and website. So easy, so crisp, so twitterpimpalishous.

Twistori: Pimp While you Sleep

For those of you out there who are daydreamers, and who love to sit around in your room looking at random shit, then you might as well get the freshest, most crispity-crunchity screen-saver out there. This high-quality screensaver pulls every tweet that contains the words: Love, hate, think, believe, feel, wish, and displays it in a masterful way. Twistori is dope.

@spam: Squash the Haters

Nobody likes a player hater. It’s not uncommon to be followed by a twitter account that is following a thousand people, but only has one follower. That means that some foo is trying to mess with your game. If you notice that you’re getting followed by these wankers, just tweet their username along with @spam, and the twitter unit goes in to lay a beat-down.

I also do the same thing whenever a lame-ass car company tries to follow me. It’s not like they’re bad people or anything it’s just not cool.

Ego for iPhone: Cuz every player’s got one

Right now, Ego for the iPhone is the nicest analytics app out there. Keep tabs on how many people are subscribing to your blog, see your twitter stats, and your mint analytics, all real time, whenever, wherever. Trust me, it’s addictive.

There you have it folks, don’t forget to get at your boys @camwest and @maxcameron.

Thu 12 Mar
2009

An Experiment in Simplicity:  Website Minimalism in the Age of “Too-Muchie”

Posted at 9:07 AM by Max Cameron Project Management, Startup 101

What does a technology company really need in a website? Not as much as you'd think.

A funny thing happened last week: I opened up my twitter client and saw this:

I love my business partner Cameron. Many people think he’s just a programmer. But he’s not. He’s a super-ninja, he whoops ass without breaking a sweat, his fingertips are insured, he’s not allowed to touch sharp objects; he walks silently through forests. So how could I be surprised that he snuck under the radar and gave me a wonderful present when I least expected it?

That’s just what super-ninjas do.

Photo By: scion_cho

So I decided to check out our new digs, and what I found was a bastion of modern simplicity. It reminded me of how I felt growing up in my family’s house. Anyone raised around modern and post-modern furniture knows what I mean when I say that. When you encounter simplicity on that level it affects you. It changes you.

So what did Cameron do exactly to our site?

• Ninja-starred our homepage
• Flying kicked our portfolio
• Head-butted our Contact Form
• Kung-Fu chopped our About Us page

And when the dust settled, all that was left was:

• Our blog, which is now our homepage.
• Our product page: for our ice-breaker application for the iPhone.

I see web-development shop websites this way: You have a certain amount of space. Your total amount of space is equal to X (an abstract value). Your visitors will divide their attention across all of X. If X does not equal completely awesome content, then you are wasting space and time. Heidegger wouldn’t be too happy with that now, would he (I’m waiting for my sister’s opinion on this one).

Photo By: JMads Boedker

We looked at our old site and said, “Our best content is on our blog.” Our portfolio wasn’t convincing (our most significant client, representing over 90% of our income has us on an NDA). Our “about us” page was filled with pretty typical copy, and we never received one legitimate contact or cold call from anyone.

But don’t get me wrong; we turn down far more work than we take on. It just comes from our social network. It comes from our client-referrals; it comes from hanging out at bars, and sometimes even at house parties. It comes from our reputation, which is small but growing slowly. But really, we get to turn down work because people who know us know how hungry we are, and they know it’s dope to spend time with a few fresh ninja dudes like ourselves.

Photo By: fredlet

Now consider this: If someone in the industry comes across one of blog posts, and starts reading it every once in a while, she will develop a closer relationship with us than if we had a very pretty portfolio hanging on our front door. How much can you tell about a company by some screenshots and a case study anyway?

Can you tell if the developer is contributing to open source projects? Can you tell if the developers are constantly learning and educating themselves? Can you tell that the company you might engage is neck-deep in the internet and can’t imagine a life without it?

Most importantly: Can a portfolio tell the story of who you are and why you love to do what you do? Maybe, but ours didn’t, it didn’t even come close.

By getting rid of everything we considered to be low-value content, and presenting a much more intimate view of our personalities, motivations, and passions, we’re telling our visitors: let’s drop the pretentions, this is who we are – and this is how we think. Come back tomorrow, we’ll probably have something else that’s interesting or useful (or immature and hilarious) to read.

To paraphrase the great Doc Searls, “If you’re going to run around naked, you better not have saggy man-tits.” So last week we took our skivvies off, busted out some tanning oil, and now we’re literally running naked across the soccer field we call web development.

Photo By: Rebel Roundup

If you’re going to be bold, and get naked online, here’s one piece of advice: don’t stop blogging. Trust in your buffness, trust that you will become more buff, and trust that people will see that attitude in you and respect you for it.

No bells and whistles. Just the goodie-goods.

Tue 10 Mar
2009

Ten Reasons to Meet Complete Strangers with your iPhone

Posted at 9:20 AM by Max Cameron

We're breaking down the top-ten reasons that you should download our ice-breaker app, Astroscope. And we haven't even announced our contest yet tee-hee.

10. It’s just plain fun. Maybe it’s just me, but I’m sure there are a few of you out there that just like to stir things up at a party. Typically I’ll think something like this, “Man. I’m already at this art gallery and the beer is free and the art is good but it’s sort of boring in here. It doesn’t have to be this way.”

Photo By: Michael Flick

9.It’s original: Until our application becomes a household name, you have a better chance of being eaten by a wild man-beast than of meeting someone that knows about Astroscope. When you’re meeting strangers, being original can take you a long way.

8.You can help your friends: If you’re already in a happy relationship, jaded by heartbreak, or already know too many people, Astroscope can be used and used again, for all your friends. Note, we do not recommend using Astroscope more than once per venue (twice maximum). That tends to kill the whole “original” vibe we’re going for.

Photo By: Perecca

7.It’s good for the world: Make a stranger’s day by introducing yourself to them. People want to meet each other; it’s just a difficult thing to do sometimes. Contribute to the overall well-being of our society by introducing yourself or a friend to a complete stranger.

6.You become the prize: A lot of times, when you approach a complete stranger, you come across as a chaser, or someone that has a hidden (usually devious) intention. Astroscope changes that because you become the object of a predetermined fate. As I wrote before, the recipient now has to wonder and ask why your fates have been thrown together. Maintain the mystery and avoid bad intentions.

5.Chicks dig horoscopes: Studies prove that chicks dig horoscopes. I actually have no idea if that’s true, but that’s not even the point. The point, rather, is that we discovered the Nobody-Suspects-the-Butterfly Effect. It’s sort of like a Trojan horse.

Photo By: myhsu

4.Forget the pick-up lines: They never helped anyone anyway.

3.Avoid Sausage Parties: Everyone knows what happens when you stop meeting new people. You hang out with your bros and you suddenly become ok with being at a party that has a 9:1 male to female ratio. I think I just puked in my mouth a little bit.

2.What’s the worst that can happen? Well, it depends. We do not suggest using Astroscope on someone that is blatantly with their muscly boy/girl friend. Although, I have done this and gotten away with it. That's because, I'm pretty awesome, and people don't like beating guys up that wear cardigans.

Photo By: I'm Combing My Hair

1.You find out a lot about someone by how they react: Astroscope lets you avoid party-poopers because you'll know right off the bat whether the person you talk to has any semblance of a sense of humour, spontaneity, or playfulness. Astroscope in this case acts like a buffer to people that just aren't cool.

I’m sure there’s a million other reasons why you should download our application, but these are just the beginning. Look out for more top-ten lists to come, including:

• Top ten tips for not being a complete duche-bag.
• Ten ways to keep your buddies and your girlfriend.
• Ten tips on how to use Astroscope.

Fri 06 Mar
2009

No Free Lunch: Building an iPhone Application Harder than it Seems.

Posted at 5:28 PM by Max Cameron

Building and marketing your iPhone application isn't as easy as one might have you think. Here are some tips to help you get through the first month.

Since the beginning, our plan has been to grow slow and grow strong. Astroscope is just starting to catch on. We’ve reached people in Australia, Switzerland, the United States, and Canada. But I should be honest: we only have forty customers. Not four-thousand, not four-hundred, forty. A lot of people would say that forty people is nothing. Zero, zilch, nada.

A lot of people would be discouraged if they were in our place. They might think that since they didn’t hit the top-100 list on the Appstore in the first week that they failed. Some of them would probably give up, try a different idea, and move on to the next big thing.

But that’s not us, and that’s not how we think. Our first forty customers are the ones that we appreciate the most. These people took the time to engage us, read what we had to say, think about our ideas and how we see society. They took a chance on the work and ideas of two guys that think they have something to contribute. So I want to give a special thanks to everyone who’s helping us reach our goal. Boo yah ka sha!

Photo By: Lord Henry

We love our customers, because our customers are willing to take chances. They took a chance on us, and they take a chance every time they decide to meet someone spontaneously: Our customers like a challenge.

So here’s a challenge for all of you.

Not everyone has an iPhone. I bet a bunch of your friends don’t have one. I bet a bunch of your single guy and girl friends don’t have one. Cameron and I aren’t like a normal company. Normal companies don’t want you to share what you bought with your friends. We’re different, we do. So we challenge you to help one of your single buddies start a conversation with a complete stranger. Unfortunately, we can’t afford to reward you if you pull it off. But please allow me to make a suggestion:

1. Make a bet with your friend. Show them the application, and say, “if this works you gotta buy me a beer.”
2. Ta-da.

Photo By: rthrelkeld

It works because your buddy will gladly buy a beer if it means he can chat up a stranger. Well worth it, he’d say. Then you can feel good because you only spent a dollar on this app, your buddy’s chatting up a stranger, and now you have a full pint!

Forty. Four Zero. The big Four- O. Not a lot you say? Consider this: Let’s say one night, forty individuals choose to start forty conversations using Astroscope. When you take into account the other half of that conversation, you suddenly have eighty people who just met someone new. Not bad.

Let’s say the next weekend, the same guy goes out with his buddies and two of them use it (at different bars, remember that!). All of a sudden that’s eighty conversations, and 160 people met in one night using our application. Now that’s awesome. And if our forty customers do that every weekend for a year, that means 8,320 met using our application. Now that’s powerful.

Wed 04 Mar
2009

Reading Between the (pick-up) Lines

Posted at 5:18 PM by Max Cameron

Everyone knows pick-up lines don't work. You might as well just go home. Our ice-breaker iPhone application breaks that vicious cycle. Astroscope: Forget the lines

When I imagine guys using pick-up lines on attractive women, I picture the following sequences:

Him: “If beauty was a drop of water, then you'd be the ocean.”

Her: “Thanks! But fuck off.”

Him: “Hi my name is Chance, Do I have one?”

Her: “Hmmm, not sure, but my boyfriend has a 100% chance of whoopin yo ass.”

Him: “Can you give me directions to your heart? I've seemed to have lost myself in your eyes.”

Her: “Yeah sure, take a left two blocks past YOU SUCK.”

Photo By:hfabulous

Funny eh?

No, not really. If you can believe it, these things actually happen every day. Women have been forced to deal with this type of behaviour for far too long. Why do men put themselves (and others) through this embarrassing and awkward ritual? I don’t think men are inherently stupid, or want to embarrass themselves: They’ve just been tricked into thinking that pick-up lines work.

As I wrote before in a previous blog post, I trace the wide variety of the world’s woes to the fact that people are lonely and unhappy. Economic recession, war, global warming, and pandemic diseases persist because humans haven’t figured out how to meet people. If we were all happy and satisfied with our personal lives, we would learn to care enough about the world and its inhabitants that we would all seek a just and peaceful coexistence.

Before Astroscope came along, the fate of the world rested on the notion that a pick-up line was the best way to meet a stranger. Of course, there’s always been other ways to meet new people: friends introduce each other, you meet people at the office, sometimes random things happen at the perfect moment and a conversation starts up. But what are you supposed to do when nobody's around to help you out?

Photo By:animalvegetable

Why pick-up lines don’t work:

Pick-up lines are:

Disrespectful: They insinuate that the girl you want to talk to is actually stupid enough to take your line seriously.

Boring: *Yawn* Do you really think you’re the first guy to say that?

Typical: Now the girl you wanted to talk to has lumped you into a pile with every other wanker that’s tried to chat them up with a busted-ass pick-up line.

A sign of weakness: You’ve recklessly thrown your cards on the table, and given up any hope of seeming innocent or interesting. Pick-up lines scream: I desperately want to hook up with you and I’m even willing to degrade myself (and you) to get there.

Lame: Guys know how stupid pick-up lines are, but they use them anyway. If you know your hockey stick is weak and held-together by duct-tape, are you really going to take a hard slap shot? In other words; they zap your confidence at the moment you need it most.

Impersonal: By their very virtue, they can be used on anyone, and they’re interchangeable.

Dead-Ends: A pick-up line doesn’t lead to an interesting conversation, because it doesn’t engage the other person at all. It’s a one-way message.

The great part about Astroscope isn’t what it does, but rather what it doesn’t do: Make you look like a typical guy spitting out a typical line. Meeting new people isn’t as simple as pressing a magic red button. Pick-up lines are easy to see through, disrespectful, and boring: so forget the lines and take your phone to the streets.

Here’s how Astroscope avoids every pitfall known to pick-up lines:

Astroscope is NOT:

Disrespectful: Because Astrsocope isn’t a pick-up line, but rather a bizarre and exciting prediction, you don’t come across as an aggressor, you’re just as confused as any other person would be if faced with the same reality.

Boring: You most likely are going to be the first person that’s ever approached a person this way.

Typical: Because nobody else has ever approached a person like you have with Astroscope, you cannot be compared to anybody else in the world. That’s a good thing.

A sign of weakness: Your cards are still comfortably in your pocket. The fact you didn’t use a pick-up line means that you’re not necessarily concerned with getting into someone’s pants. You’re just an innocent bystander that has been confronted with an unusual prediction that concerns you as much as it concerns the person you show it to. You’re shocked and surprised, and you’d probably rather be doing your own thing and minding your business. And best of all, you don’t look needy. Now it’s the other person’s turn to wonder exactly why they were mentioned in your horoscope. Nobody’s to blame but fate itself.

Lame: Be bold, especially the first time you use Astrsocope. I remember that I was sure this girl would shake my iPhone, laugh at me, and walk away. But she didn’t. In fact, only 1 in 10 questioned the prediction at all. Once you discover this for yourself, and you learn how to keep a straight face, your confidence will render the tool even more powerful.

Dead-end: Because each horoscope was crafted with care, each horoscope predicts that you have a lot in common, and provide a basis for immediate engagement at a conversational level.

A conversation with Astroscope

Me: (walk up to a girl and do a blatant double-take. Shake my head, make an ugly face, then approach her, almost irritable.) “Excuse me, but I think I’m going crazy. My horoscope predicted that you we were going to meet today. This is weird.”

Her: (She looks confused, and thinks I’m trying to pick her up) “Um, what are you talking about?”

Me: “Yeah I know, my buddy over there (motion to attractive female wingman) wants to leave but I had to show this to you first. Take a look for yourself.” (I hand the phone over to her).

Her: (reads the phone, notices her clothes match the description, looks up) “This is crazy. This can’t be real, can it?”

Me: “Yeah I know, I’m just as scared as you are. “ (I pass the phone to her friend and ask for a second opinion. While that’s happening, I start talking to the first person some more, and start asking them questions.

That’s how 90% of Astroscope conversations happen for me, without any exaggeration or fanfare. Like I said before, there is no magic button, and Astroscope can’t take you any further than getting an opportunity to ask a smart question. But, it gets you that far, and that is remarkable. That, my friends, holds all the potential of saving the world as we know it.

Mon 02 Mar
2009

Ringtone Applications Dominate iPhone Appscape: Traditional Developers Forced to Adapt

Posted at 9:36 AM by Max Cameron

There’s an identity struggle tearing the iPhone Appscape apart, pitting sophisticated software against cheap, novelty iPhone applications. Here's where we weigh in.

Some very prominent iPhone developers have argued that the proliferation of Ringtone applications is degrading the overall quality of the Appscape, and threaten the success of the platform as a whole. We can't help but disagree.

Introducing the Appscape

This opposition is generally rooted in deep concern over the way the iTunes Appstore operates, which is complicated by the dual interpretation of the Appstore as a marketing channel as well as a point-of-sale.

I contend that the controversy over the success of Ringtone applications reveals a failure of some developers to understand the emerging Appscape and the place of the Appstore within it. This, in turn, illuminates the critical dependence between Big Developers and Apple. At this juncture we now must face an uncomfortable fact: stop depending on the Appstore as a marketing channel, or face extinction in the face of a changing Appscape.

I Don't Feel Bad for You.

Let’s recap the discussion relating to Ringtone applications, and the complaints levied against them by some reputable but traditional iPhone application developers. Craig Hockenberry, an industry veteran and master app developer (Hockenberry developed Twitterific), came out swinging when he argued that, “This proliferation of 99¢ ‘ringtone apps’ is affecting our product development.”

Photo By: John Smith

Ringtone apps, he argues, are flooding the Appstore, and are stealing prominent positions on the top-100 lists, which Hockenberry argues is crucial for the success of an application. Therefore, his company cannot risk developing more resource-intensive apps, and have to develop apps for tier-one pricing.

How can one developer make decisions affecting the entire Appscape? Especially when the product he wants to bring to the market are so clearly associated with one side of this very important debate? Ringtone applications present us with this dilemma: Some applications can be contextually useful, without bringing a lot of functionality to the table. Our ice-breaker app is a perfect example. In a specific context, Astroscope will outperform twitterific twenty times out of ten. You can't just walk up to a girl at a bar and say, "Whoa, check out this twitter client application, isn't it just SOOOOO sexy?" No, you can't. Software is contextual. People need to understand that. And anyone that decides they have the right to demean and ridicule software like this ends up sounding like an elitist snob. Don't be bitter. Get smarter.

A number of other important developers have criticized (sometimes poignantly) the way Apple ranks iPhone applications in the store, and many argue that the proliferation of ringtone apps is leading to an overall decrease in iPhone application quality.

Here’s a list of the most common gripes:

• Ringtone apps are dirt cheap and therefore skyrocket to the top of the charts.
• Higher-priced apps can’t stand a chance of competing as the appstore currently operates.
• High-quality apps are left undeveloped in favour of better placement in the appstore.
• As the Appscape continues to grow this problem will only become bigger.
• There are fundamental flaws in the Appstore which reinforce this trend.

Solutions... Sort of.

A few other developers have proposed solutions, which address the misgivings of the iTunes Appstore, without grasping the real problem: they’re treating the Appstore as marketing channel, and expecting way too much. Their ideas are still worth taking into account:

John Casasanta & Phill Ryu propose that “Instead of basing app rank on the number of units sold, base it on gross gross revenues.”

Andy Finnell proposes, “The fix for pricing too low is really simple: raise your prices. Most $0.99 apps should become $9.99, $4.99 apps should become $14.99 and so on.”

And while I believe that the Appstore definitely has room to grow and improve, especially when it comes to browsing and finding cool new applications, I fundamentally disagree with Finnel, who proposes price-fixing (isn’t that illegal in the real world?) as well as measuring popularity based on gross revenues. Reaching a lot of devices is really important for me, and I don’t believe developers should be punished for providing smart, simple, contextual software that really is only worth a dollar.

Shipley has Major Skittles

Wil Shipley, the very talented developer behind Omnigroup and Delicious Monster, has shifted the discussion in a great way, and one that instigated an aha-moment at our office. He writes,

Wil Shipley on the Appstore

“The App Store needs to think of itself as two different parts - it already implements these parts, but the people who run the store need to understand that these two parts are fundamentally separate: Part one is a giant warehouse, where every piece of software that is not actively harmful is kept in case someone wants to buy it (remember, users can always get a refund). This warehouse can be searched with titles and keywords or an item can be directly linked. Part two is like a traditional storefront, with limited real estate, so only the best or coolest applications are highlighted. It's a recommendation engine, that highlights popular, highly-rated, or innovative applications."

What Appstore?

I’ll take it one step further and propose that we ignore the second part of Shipley’s analysis altogether. Any additional sales resulting from free promotion in the Appstore should be seen as a reward for making Apple money by selling our applications in the first place. The only way to survive in the new Appscape is to take responsibility for your own sales. Anyone who isn’t willing to do so will fall behind the new companies that do.

I think iPhone developers and recording artists have a lot in common, especially when it comes down to separating the concepts of marketing and distribution. The recording industry had a lot of time to develop sophisticated means of producing, promoting, and distributing popular music. They came up with all sorts of pop charts, opened up stores, printed posters, packed arenas and sold concert tickets. This apparatus had a disproportionate amount of control over the music that the public could consume through mainstream channels.

The inherent problems in the pop-chart system, which has always been characterized by corruption, never really did a great job at promoting “good” music, it promoted what the record companies wanted to promote. That's why Britney Spears and 50-Cent dominate the charts. That's why I ignore pop-charts.

The Appstore is on the verge of heading down the same path, except there is one big difference: the content producers (IE the developers) are in a much more powerful position than their musical counterparts. We have the ability to benefit from the Appstore as a distribution channel, while maintaining strict independence in terms of marketing and promotion. We are not dependent on Apple like Britney Spears is depenedent on Wal-Mart. That’s a good thing.

Shipley’s comments illuminate Hockenberry’s old-style attitude and dependence on Apple as a marketing channel. The Appstore, and Apple, have provided developers with an amazing tool. Point of sale has always been a tough thing for software companies, and I see it as the biggest obstacle behind the large-scale proliferation of social software. They’ve provided a really nice solution to that problem, and they should be commended for having that vision.

Don't be a baby

Developers need to take responsibility for marketing their applications. This is the only way that the Appscape has any chance of surviving and thriving in the future. I also believe there will always be problems with the way that the Appstore measures success, because any chart system is inherently flawed. There is no one metric for measuring who deserves to be rewarded. Regardless of Apple’s actions, the Appscape is growing and will continue to grow. This entity will be heterogeneous, diverse, contextual, and marketing channels need to reflect that diversity.

Here it is, plain and simple. If you’re so preoccupied with landing your app on a top-ten list that you decide to wage war on the little guys, you should have put your energy into writing a better story, making a stronger argument, or being a better developer. The guys at the bottom of the ladder, who have learned to survive and even prosper independently of Big Business, can engage Apple selectively in order to sustain long term success.

Our commitment to ourselves is to be self-reliant and responsible for our own success. We will inevitably be rewarded with the freedom to create the software we want to make, without worrying what other developers are doing. It's a big Appscape: some of us are skyscrapers, but most of us aren't. And you know what? There's room for all of us.

Wed 25 Feb
2009

Astroscope Will Change the World

Posted at 6:35 PM by Max Cameron

It appears that our last blog post didn't quite grasp the full reality of our challenge, or of our opportunity. The stakes have been raised, and we are ready to respond.

No Looking Back

Ever since we naively unveiled the most powerful and compelling ice-breaker application ever written for the iPhone, and kicked-off our Drive to Start 1,000 Conversations, we’ve realized that accomplishment comes with devastating responsibility. We have unwittingly decided to directly confront the most important, historic, and complex challenge ever faced by mankind: Starting the first conversation between a man and a woman. We have, as it appears, rested the fate of the world upon our shoulders.

At first glance, this global and immemorial challenge appears all too simple. Aren’t there more important things in the world than finding ways for men to meet women? What about war? What about poverty? What about famine, disease, global warming, and systematic political oppression? How can you compare loneliness and heartbreak to the all-too numerous horrors of our time?

To these challenges we must respond; how could one wage a war if not fueled by greed and the desire for power and control over others? Imagine the psychological state of any devious criminal, crooked politician, horrific dictator, or greedy Wall Street investor. What drives these men to hurt and control others? Furthermore, what prevents men from stepping in to put an end to atrocities they know are happening around them?

The Banality of Evil

In times like these I think of the philosopher-journalist Hannah Arendt, whose analysis of the origins and nature of genocide are as true today as they were in the late-forties. She asks how this type of disaster could actually take place. Were the people who committed the crimes exceptional in some way? The devastating scope of their actions begs the question: were they super-villains? Arendt famously concludes by declaring the banality of evil, illuminating why the worst horrors of the world are not as unimaginable as we would like to think. Regardless of the implications for the human condition, the most offensive practices are committed by the most normal of people. And the most normal of people struggle with the most universal of problems.

I argue that loneliness and heartbreak, rejection and humiliation, if repeatedly endured, can slowly erode any sense of morality, respect, and justice towards others. Because behaviour is cyclical, and communicated across generations and cultures, I argue that loneliness leads to war, oppression, greed, and the need for control. Loneliness and heartbreak can leave a heart jaded, and leave a man unwilling to step in to prevent genocide, or fail to do everything possible to contain and eradicate pandemic diseases. By building as many good relationships in our society as we can, we're laying the framework for a just and peaceful future for everyone. Good things happen when people get together.

Hope Emerges

I know this because the inverse is true: Love is the great muse of humanity. The power of good can always and indisputably triumph over evil. Cycles can be broken. Respect breeds respect, and love reproduces more love. True love between two people, in other words, can go viral in a way a YouTube video cannot. If we can help one man meet the right woman, we can change the tide of mankind. We can save the world, one relationship at a time.

The greatest warriors of our modern era would agree: Ghandi, Bob Marley, Mother Theresa, the Dali Lama, would probably agree that love is in fact our only hope of salvation as a species. And if the argument that love can change the world is accepted, the next natural question that emerges is how our goal could be accomplished. Such an eternal, powerful, and complex challenge must require a solution that is equal in complexity, size, and power.

Simple is Better

Think about David, as he turned down Saul’s armour, taking only a sling and a staff to combat Goliath, the most fearsome Philistine warrior ever seen. Goliath was capable of striking fear into the heart of the bravest Israelite, and none of Israel's warriors, even with their most powerful weapons, would take one step in Goliath's direction. Think about the simplicity of David’s weapons, the simplicity of his belief in the power of good over evil, and his conviction and courage in confronting the very embodiment of evil.

Think about the Mothers of the Plaza de Mayo in Argentina, who stood up to the most fearsome political Junta that nation had ever seen: armed only with photos of their disappeared sons, young boys who those mothers loved dearly. They did not bring guns to their protests every Thursday afternoon, no, they only brought photos. And many credit these grandmothers, these feeble old women, with breaking the deadly silence that had defined the political reality of their time.

And now think of us, two young Canadian boys, who work from a bachelor apartment, who have forgone high salaries in the corporate world because our belief in the power of our ideas. We have created the modern sling and staff; we have brought to you only a picture of hope. We have come to you with a request that you use our simple tool to accomplish the impossible. We ask you to join us to help save the world, one relationship at a time.

Tue 24 Feb
2009

Saving the World: Drive to a Thousand Conversations

Posted at 10:53 AM by Max Cameron

Today we're proud to announce our Drive to Start 1,000 Relationships facilitated by Astroscope, our ice-breaker app. We're saving the world, one conversation at a time.

The Crisis

Every day, tens of millions of decent, honest, single men - young and old alike – wake up thinking that today could be the day they meet the person they’ve been longing for. In art galleries, bars, restaurants, shops, and offices, the possibility of meeting someone new holds all the promise of potential happiness. But all too often, men lack the confidence to initiate that first conversation. They stand and talk, sip from bottles of beer, peer at their cell phones, and pretend to act macho so their weaknesses may not be revealed.

And, more often than not, they return home alone at the end of another long night, with neither a phone number nor an email address as a symbol of their progress towards their goal. And I ask why: these aren’t unattractive men, they’re not grotesque or disfigured or misshaped. These aren’t unintelligent guys, they’re not feeble or awkward or depressed. No, these are normal, every-day guys, who may be imperfect, but no less deserving of the care and affection that most take for granted. I should know, because I once counted myself among them.

Consequences

When a man loses his confidence, terrible things happen: Ex-girlfriends get booty-called, sausage-parties emerge, prostitution flourishes, pornography wins, real relationships lose - this is not the dignified life that we all deserve.

There are men who have acquiesced to living a life of solitude. These are men who lack the confidence to make a striking and bold first impression. Men who have been repeatedly torn down and ripped apart by those women who fail to see the decent human being inside. To these men I say: we do not blame you, we do not hold you in contempt; we are understanding and you must know that we’ll be ready to help, when you’re ready to help yourselves.

A New Voice

To the men that have hope, but lack resolve; for the boys who are strong, yet shy; for the guys that can deliver, but not initiate; we are here to help. Do not despair in your solitude, for it is temporary. Do not relinquish your belief in the possibility of love, or the satisfaction and power of mutual attraction. Instead rejoice, and take heed that today, above all other days, you have friends who understand what you’re feeling, and who have been working long hours, spanning days and nights and weeks and months, to bring your nights of loneliness to an end.

We know that the striking pain of rejection can be enough to break the will of a titan. And there will never be a perfect solution to this reality. Whatever does not kill us can only make us stronger. I ask you: would satisfaction taste as sweet as it does if it wasn’t contrasted to the sinking feeling of failure and defeat? This, among many other reasons, is why we must continue to persevere, even in the face of humiliation.

Yes We Can!

And so today, we’re unveiling our plan to make our contribution to the happiness and well-being of all the guys that find themselves alone when the night is through, although that might not be their wish. We pledge to work night and day, hour-by-hour, writing line for line and word for word, until we reach our non-negotiable goal of starting ONE-THOUSAND relationships initiated by Astroscope, our ice-breaker application for the iPhone. We will not rest, we will not tire, we will give up on our belief that anything is possible.

With our technology, and your courage, we’re going to relentlessly pursue our ambitious milestone together. We will stand beside you, and give you the tools you need to start that first conversation. We cannot say for certain that you’ll get some, but we can give you a great start. Working hand in hand, we can turn heartbreak into fulfillment, sorrow into joy, Machismo into humility. Today, I reaffirm to all men, that we are created equal, and that we all have an indisputable right to the happiness we deserve.

Good luck, my friends, and Godspeed.

Also, you can read the story of how Astroscope came to be, and how Astroscope Will Change the World.

Sat 21 Feb
2009

Innovating the Game: Picking up girls with your iPhone

Posted at 1:05 PM by Max Cameron

From top to bottom and front to back, this is how we developed the concept behind our first application built for the iPhone: Astroscope.

Building Astroscope

Last week we hit a major milestone for Big Bang, when we saw our first iPhone app, Astroscope, appear in the iTunes store for the first time. It was a really great feeling for me, and even though my business partner Cameron wasn’t there to share in the moment (he was spending a well-deserved week relaxing in Cuba), I know that he must have felt something similar seeing that shiny grey icon winking up at him from his monitor.

Astroscope sounds like a horoscope app, but it isn't. Anyone looking for a typical horoscope will probably be disappointed. But, if you were looking for an app that could help you strike up a conversation, then – you can’t do much better than what we made.

Astroscope in Action

1. Find someone you’d like to talk to. Easy enough. Toronto is really good for this.
2. Shake the phone on any horoscope page and the secret editing interface appears.
3. Clear the fields and insert text describing the person you want to talk to. We chose to have two fields for clothing, and two fields for characteristics.
4. Press save. And ta-da. A very bizarre prediction appears in all of the horoscopes.
5. You walk up to the person and say something like, “Um, what are you doing in my horoscope.” Hand over the phone and wait for the show to begin.

The magic is in the details: The horoscopes are unique for each astrological sign. I wrote them my own damn self. And although they refer to some generic characteristics of that sign (it was fun researching that contrived bullshit), they’re effective on a deeper level. In addition to predicting what the person you’ll meet will be wearing, the horoscopes focus more on how much you’ll have in common, and how easy the conversation you’re about to have will be.

Here’s an example of one of the horoscopes:

Capricorn (Dec 23 – Jan 30)

“Capricorns are goal-oriented, driven people. But today is all about keeping expectations low, and letting yourself take a chance. Keep your eyes out for someone wearing black jeans and brown leather boots. They’ll also have black hair and a lot of confidence. If you have the courage to be honest, they’ll appreciate what you have to offer and return the favour. Have faith in your ability to communicate what’s inside your head, you won’t be sorry.”

Here how Astroscope gets the job done:

• "Capricorns are goal-oriented, driven people." We want to come out of the gates running. This sentence says I’m confident, successful, independent, and don’t need anyone to validate me. That’s a good, bold introduction.
• “But today is all about keeping expectations low, and letting yourself take a chance.” Hold on a second. I’m not here to get in your pants, and I’m actually sort of sensitive and sometimes I guard myself from being hurt. This draws a nice contrast to the first statement. After all, everyone has his or her moments of weakness.
• The next sentence identifies the intended participant. Even though there are only four fields, which seem restrictive to some people, you can play around with the words you choose to make a fluid sentence. This was a decision we made in order to minimize the amount of text that the user has to input.
• “If you have the courage to be honest, they’ll appreciate what you have to offer and return the favour.” This is a trick sentence. It seems to bestow honesty and courage upon the person using it, which continues to foster a positive self-image. It also sets the stage for the recipient to reciprocate the good will. Now the recipient can feel comfortable being engaged because we’ve already predicted a positive outcome. The sentence alleviates the stress that is usually associated with a first encounter.
• “Have faith in your ability to communicate what’s inside your head, you won’t be sorry.” I chose to end this horoscope with a sentence that would focus on what I see is the most important social skill a person can possess: good communication. This is the closing argument. We just established that regardless of the outcome, you have the right foundation for a good conversation.

Technology as Antisocial

Typically people love to bitch and moan about how social technology is antisocial. Think about all self-conscious web addicts that haven’t left their homes in months, preferring instead to live on the web, interact on facebook and play World of Warcraft with a million other sweatpant-clad technophiles. Think about awkward dudes leaning against the wall at a nightclub, checking their text-messages every five minutes but not talking to anyone or dancing or anything. What a loser.

This is the unfortunate association that technology has accumulated over the past few years. Technology isn’t sexy, people say. Technology can’t get you laid. Yeah maybe there are a few rock-star programmers and designers who have a life outside of Macworld, but for the most part technology has been relegated to an awkward place in our society. You should feel embarrassed if you spend too much time on facebook. Someone told me the other day that they came across a really cool picture while they were “creeping” my facebook profile. Think about that.

We need to break down the vision of social technology as interrupting or repressing people’s social-lives. Right now people see technology as a way to escape interpersonal interaction and to hide from the realities of real social situations. We need to create technology that does the opposite: we need technology that we can take to the streets.

Here’s how we decided to break down the painful association between technology and a life of lonely solitude. One night while we were out for beers with Tim, a grizzly web-dev veteran and former member of some fraternity somewhere (Skull and Bones? Something like that). We were chatting about all the iPhone apps that we couldn’t wait to start building. Right at that moment I saw a beautiful girl walking across the room, and I thought, ‘Shit, yes, I got it.”

Technology as the Ice-Breaker

I turned to Cam and Tim and I said, “Boys, listen. Chicks love horoscopes. We already knew that. So all we need to do is fix the game, and we’re golden. Let’s get another round.” The idea was attractive in a few ways:

1. It seemed easy. We wanted to start with something manageable since we only have one developer who’s learning Cocoa as he goes. Screw web services, to hell with GPS, we need the simplest thing we can make. Oh yeah, and Cam, do it fast.
2. We would use it. Well, I would use it (Cam has an awesome girlfriend). Our golden rule is: Only make an app that you would use (and purchase) from another company.
3. We would meet girls. Always a good place to start when you’re a guy in his mid-twenties. We chose to make an app that could hold close to our hearts.
4. It seemed plausible. We figured, all things being equal, this app would actually do its job: regardless of the outcome, it would start an interesting conversation.
5. It’s for everyone. We realized that we would look like chauvinistic pigs if we made an app that only guys could use. We kept our language gender-neutral so a person of any sex, or sexual orientation could use it.
6. Be proud of your technology. iPhones are beautiful machines. Everyone wants to play with one, but they’re not cool if you’re just checking your missed calls and acting like you’re so cool you’re bored.
7. Astroscope brings technology to the streets, to the bars, to the party, to the subway, to wherever. We couldn’t think of a better way to break down the idea that technology is anti-social.

So that’s how Astroscope came to be. It works too. The first time I actually got to use it was with a girl at Tequila Bookworm in Toronto. She freaked out, told all her friends how this guy had the craziest horoscope ever, and she just couldn’t believe it. I found it really interesting she didn’t even look at any other horoscopes, or question the fact that I had a horoscope that predicted four defining characteristics about her.

In reality, the hardest part about it was keeping a straight face.

*UPDATE* We just launched our Drive to Hook Up 1,000 Dudes with Astroscope. Help us save the world, one hook-up at a time.

Tue 23 Dec
2008

How to Build An iPhone Web App - Part 1

Posted at 2:45 PM by Cameron Westland Tutorials

I've been trying to figure out what the best way to share some of the ideas we've been coming up with over the last few months. Instead of doing a bunch of case studies, or trying to get permission from some of our higher profile clients, we've decided to do a short series on how to build an iPhone web application.

This is a fairly broad discussion and we're going to try to slice horizontally across a lot of topics. Expression Engine, MySQL, iUI, Textmate, Ruby scripting, Deployment Issues, Mobile Optimization Techniques and more will be covered. Since we're giving these videos away for free, don't expect the polish that you'll find on sites like Peepcode or The Pragmatic Programmers. Instead, you'll find a candid and casual look into the world of Big Bang Technology, and how we develop.

Part 1 : Environment Setup

• Setting up a development environment
• Creating a MySQL Database
• Installing Expression Engine
• Setting up Virtual Hosts
• Creating a dynamic deployment configuration file for Expression Engine

The videos are all high resolution 1152 x 720 encoded in H.264.

I have not provided full transcripts for the content. Sorry about that.

Produce Lookup Application Development - Part 1

Thu 30 Oct
2008

Setting Up Communication between GitHub Repositories and Lighthouse Projects via a Secure Token

Posted at 12:40 PM by Cameron Westland Tutorials

Integrating Github with Lighthouse has been a great time saver. It has allowed us to stay on top of fixes and keep track of everything we're doing in one place. We don't need to have everyone looking through the git logs now! This short screencast shows you how to get things set up.

Transcript

Hi there, thought I'd try this whole screen-casting thing out again. So this screen-cast shows how to integrate github with lighthouse. This basically will show changesets in github inside lighthouse. It will let you see what's going on straight from light house. It's pretty simple to do.

Lighthouse

All you have to do is go to your profile and generate a token, pick a lighthouse project and give the token a label. Then click create.

Now we'll just copy & paste the token that was generated. And we want to make sure we have read/write permission. Now the only thing we really need is the project id, so we'll go into the project and grab the id from the address bar. We also need the sub-domain. That's really all we need from lighthouse.

Lighthouse is all set up.

Github

We'll go over to github's dashboard. Just select the repository you want to communicate with lighthouse and edit the repository. Click services and scroll down until you find the lighthouse service. Now it's basically as simple as putting the information from lighthouse in. Make sure to set it to active and then hit update settings.

So it's pretty simple to integrate, but there wasn't any super clear documentation on how to do this.

Testing

The easiest way to test this is to update a file and push it out to github. We'll add it to the repository with a simple commit message.

git add README
git commit -m "Another test change"

And then push it to the server:

git push origin master

And finally refresh lighthouse and we see the test change. That's basically it! It shows the files that were updated and you can click through to the change-set.

Thanks a lot for watching!

Mon 27 Oct
2008

McCain-Obama Danceoff!

Posted at 9:18 AM by Max Cameron

Kudos to these guys who super-imposed the candidates faces on top of awesome dancers.

Mon 27 Oct
2008

Google Earth for the iPhone Released

Posted at 8:05 AM by Cameron Westland Technology

Congratulations to the Google Earth folks for releasing this sweet interface for the iPhone. The touch gestures are particularly impressive. Hit the jump for their introductory video.

Fri 24 Oct
2008

Thursday’s McCain Bush Palin SNL was striking, subversive, and intelligent

Posted at 10:40 AM by Max Cameron Ranting

Comedy can comment on politics in a unique way. The folks from SNL really got this one.

Mon 20 Oct
2008

HTTP Gallery in London gives a voice to web artists

Posted at 1:05 PM by Max Cameron Community

I got a kick out of HTTP gallery and particularly out of Jeremy Bailey's SOS videos. I suggest checking them out.

Jeremy Bailey's videos are really funny. They made me start thinking about an art piece I've wanted to do for a long time. So I sent London-based HTTP gallery an email. I've included the email in this post. They specialize in web art, so hopefully they'll get back to me.

Fri 17 Oct
2008

Towards a better client survey: Part Five

Posted at 2:28 PM by Max Cameron Project Management

In Part Five of Towards a Better Client Survey, we take a look at the next section of Kelly Goto's client survey: Current Site.

To (more or less) quote Barack Obama, in order to understand where you want to go, you need to know where you're coming from. If your last website was as economically viable as the last eight years of Republican rule, then maybe it's time for some change. But you don't want to use a hatchet when you need a scalpel (oh this is fun!), and the goal is to strengthen the parts of your project that work, and eliminate the parts of your project that are under-performing.

The first two questions are standard questions that you would expect to find:

What aspects of your current site work well and why are they successful?

and

What aspects of your current site are unsuccessful and why do you think that is?

One issue that we're going to be forced to address is the definition of an “aspect.” Is an aspect a directory or sub-directory? Is an aspect a strategy, or a part thereof? Is an aspect an adjective, a noun, or a pronoun? I suppose it could be all three.

Peronally, I'd like to approach this question from a different angle. I'd prefer to ask, “When you first started out, what were your hopes for your website, what did you hope it would help you accomplish? How many of those goals did it actually accomplish? And then follow-up with, where did it fall short?

Another issue about this question is that of redundancy. Is it the same question to ask, what are your business objectives for the new website? And, “what didn't work in your last website?” wouldn't one expect to see the same answers?

If you update your current site using a content management system, please describe the system and it’s main features. Are you happy with the system?

I think this question is a pretty simple and necessary question, so it's fine with me.

Tue 07 Oct
2008

Towards a better client survey: Pt 4

Posted at 4:37 PM by Max Cameron Project Management

Part four of Towards a better client survey explores the second section of the standard Kelly Goto client survey: Objectives. We examine the questions, why they're important, but why they can come up short.

You can get caught up on the conversation here, here, and here.

So you've figured out the basics. Your intended URL is available, you've identified key stakeholders, and even (gasp) received a budget range to work within. You've identified an ideal launch date, coinciding with your clients' big event. But where do you go from there? We still haven't asked the question that I believe is paramount: Why do you need a website?

Today we're going to be getting into my favorite part of the client survey, Objectives. They can also be thought of as business goals – it doesn't really matter. What matters is that you're about to identify the why of web design. I would suggest any webdev shop who's working with small clients to ask straight up: why do you need a website. If the answer your receive sounds something like, “Um, well, because our competitors have one,” or “Because you need a website! Everyone needs a website!” then your potential client just threw up a flaming red flag.

Web development is all about applying technological solutions to business problems that already exist. When potential clients fail to provide reasonable cause for a website design or redesign, it shows that they're out of touch with their audience, and perhaps with their own business. It also shows that the potential client hasn't done their homework, and probably doesn't take the web development process all that seriously.

This section contains three, short questions:

What are your main reasons for commissioning a new website?

Well folks, here we have it. The holy grail of web design. But seriously, part of me wonders why this question isn't 48 point bold capital letters at the front of the survey. Part of me also thinks that if a client could completely and thoroughly answer this question, then we'd be able to make a great estimate based on that answer alone (well, that's a bit of an exaggeration but you see where I'm coming from).

This is also the question that is most often misunderstood, written-off, or over-simplified. Really what we want to be doing is telling our potential clients that this question should encourage them to examine their business and the unearth the core challenges they face in day-to-day operation. It isn't productive for a client to call us up and talk about the technology platform they want to use (we want a website that uses flash!), those recommendations are, after all, what we're here to do.

What is useful is a potential client who says, “You know what, when I google my products, ebay listings are appearing higher up than my company's website. That must be killing us, so what can we do about it?” Or, “we're getting forty-five phone calls a day asking us where our store is located, and our sales reps are losing real opportunities on the floor.”

Things like that often slip under the radar of potential clients. We should do a better job reminding them to take a big step back and a long look into the mirror.

List the business objectives for your website in order of importance. Eg improve sales, increase customer satisfaction, reduce time spent searching for information, etc

Here's a great question. But it's a question that requires a client to be savvy and informed about the possibilities the web has to offer. In other words it assumes that the client knows a)the business challenges that they face and b)how those challenges can be addressed on the web. Wouldn't we be better-served if we just asked, “list your business objectives in order of importance?” Usually our best ideas that we pitch to clients, the ideas that get people really excited about redesigning a website, are the strategies that address their business objectives ("You mean, our website can do that?). So instead of asking them how the site itself should accomplish objectives, we should just ask for the objectives and put our money where our mouthes are.

How will you know if the site is a success? Eg 20% increase in sales, 70% of surveyed users expressing satisfaction, 30% reduction in time spent searching for info.

This is a complicated question, and it's extremely important. Not only do we recommend getting this question answered before setting out, we recommend that you make your clients sign off on the metrics that you'll be using to measure the success of your redesign. Furthermore, ensure that your clients actually believe in these metrics, and stick to them.

But it gets hairier (sp?). In our industry we know that statistics are only as good as the ones you're comparing them to. What do you do when a client comes your way saying, “we got a MILLION HITS last year!” Make sure your new client is bringing reliable and reasonable analytics to the table. If they're not, then don't even bother using them. Either track their old site for a month or two using correctly-installed GA code, and use that as a metric, or if you can't wait, consider the metrics you'll be using for the first two months and build from that point on.

So here's my micro-conclusion:

When I first saw this section of the survey, I had high hopes. There were three, short questions. But upon closer examination, I think that we might not be saying enough. Every client has her or his own way of assessing their business and the challenges they face. Every client has different ideas about how the web can help them out. But the more I think about this survey, the more I see a need for direct communication where these ideas can be really be teased out and given their full weight.

I think we can take some lessons out of this exercise and use them to inform our website survey redesign, and consider how the observations gathered today can inform how we frame our questions, how we deliver them, and what we must emphasize when navigating this process. I hope you can join me next time when we discuss the assessment of the client's current site.