Big Bang Technology Blog

RFPs Will Kill Us All

2009-10-27T19:34:57Z

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.

Agency Life: The Meeting Before the Meeting

2009-10-14T20:30:50Z

My second episode in the series. Inspired by a very funny website.

Agency Life: Good Morning Sheldon

2009-10-06T13:31:28Z

For all of our friends at big agencies. Inspired by a very funny website.

The Art of the Referral

2009-09-23T23:08:41Z

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.

The New Start Ups

2009-08-19T20:36:15Z

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.

How Balsamiq Mockups is Inspiring our Start Up

2009-08-13T15:14:28Z

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.

The Critical Period of Software

2009-08-07T16:13:20Z

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.

Links of the Week 3

2009-08-04T22:32:10Z

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

Links of the Week 2

2009-07-29T02:55:12Z

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.

Software is a Journey

2009-07-24T18:01:45Z

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

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.
SEA to YVR: Might as well get the border crossing out of the way sooner rather than later.
YVR to YQR: Not sure what's in Regina, but I have a funny cousin named Erin who lives there.
YQR to YWG: I love Winnipeg. It's where wild things have been known to happen.
YWG to YQT: I hear they have a solid minor league hockey club in Thunderbay.
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.

Links of the Week

2009-07-18T20:22:20Z

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.

8 Things We Need to Work with an Angel Investor

2009-07-14T14:09:50Z

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:

We don't want to engage the clients that you maintain (no side projects, marketing sites, or sales meetings).

We need to have secure financing, every month, without fail.

We need to establish expectations for this product together, and stick to them.

We need two stakeholders in this project (Us, and you). Only expert opinions should be considered when evaluating new features.

We need to make our own product, and own a fair portion of it.

We need to know our operating budget.

We need to resource this project as we see fit.

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.

Twitter Developer Diary

2009-07-11T16:11:46Z

From the looks of things I'm not going to be writing a lot of essays like Max. I'd like to still be active though, so we started Big Bang Developer Diaries. We may not talk specifically about the project we're working on, but at least we're talking. Inspired by Brent Simmons.

The Meaning of the Small Corporation

2009-07-07T19:40:23Z

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

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.
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.
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.
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.
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.
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.

Mobile Orchard Beginning iPhone Programming Workshop in Toronto

2009-06-25T20:29:42Z

On July 9th and 10th, Dan Grigsby, creator of Mobile Orchard, will be leading an iPhone Dev Workshop as part of Future Ruby. You can check Dan's twitter page to see if you like his style. Dan's not a T.O. boy, so when Stephen from Zetetic put us in touch, I was more than happy to do my part and help spread the word. Good luck Dan, I'm sure the rest of the Toronto tech folk will make you feel right at home.