Safe from the Losing Fight

I’m easily provoked into rambling, and I was recently incited by a college student, asking how I made it into Cocoa programming. Now I was intrigued because he has a similar “problem” to what I had, of being in a public state college in Tennessee (actually a sister school of where I graduated from) and trying to get into Mac programming. Because I like hearing myself talk under the guise of being helpful, I’ve decided to answer his question publicly.

Don’t all thank me at once.

My Story

The story of my rise to Cocoa fame (hey, no snickering in the back!), is both interesting and inspirational, especially if you don’t bother to check up on any of the “facts,” or know what the word “fame” means. So here goes.

First, I should point out there was no such thing as “Cocoa” when I was in school. It was all Toolbox, non-opaque structure, procedural, event polling, love. But since that’s what Mac programming was, that’s what I taught myself during college. I even wrote three tiny freeware products and released them. (Please don’t google for them, that’s exactly the sort of blackmail material I don’t need.)

Second, I got a lucky break. After I graduated from college, the Macromedia Texas office happened to be hiring. I managed to con them into taking me, undoubtedly dazzling them with my total lack of experience, huge ego, and inability to correctly pronounce the word “boil.”

Third, Macromedia fortunately turned out to be a large uncaring corporation that sufficiently pissed me off enough to curse them and leave. Then I went to work for myself as a Cocoa programmer.

The End.

hmm… maybe that isn’t as inspirational as I first thought.

Where ever you go, that’s where you are

OK, in all seriousness, there are things you can do to increase your chances of being a professional Cocoa programmer. The first thing to deal with is your location. There aren’t many (read: none) Cocoa jobs in Tennessee or most of the southeast. So you’re going to need to find your ticket out of Squaresville.

I did it by being hired by a large company, Macromedia, who paid for my move. They moved me to Dallas, which, being a large city, has more Cocoa opportunities and hail storms than Tennessee. One of the things that helped me get hired was that I had previous Mac programming experience, and that I had released some freeware. Real word experience, whether you made money off of it or not, goes a long way, especially if you just graduated from college.

However, I should point out I really didn’t get to be a Cocoa programmer at Macromedia/Adobe. Most of their apps are Carbon based (like me) and I don’t see that changing anytime soon. It will probably be a similar situation at most large companies with established products. At the time of my departure, the only shipping Cocoa app Macromedia had was the Extension Manager, because I rewrote it in Cocoa in my spare time.

Anyway, my point is you need to find a way to a city with more tech jobs, like San Francisco, New York, Boston, Raleigh, D.C., or, to a lesser extent, Dallas or Austin. It’s the only way to a Cocoa job and true happiness.

Don’t be a sucker

So I was actually lying about having to leave Tennessee to get a Cocoa job. Only suckers do that.

The best way to be a Cocoa programmer is to just be a Cocoa programmer. Work for yourself; create your own products. Of course, there is the whole problem of making money. It takes a while to establish a product (usually a few years) and sometimes weak people need to eat in that period.

When you’re self employed there are three ways to generate money while you work on a product: contracting, venture capital, and angel investing (i.e. your parents). Contracting is what we do, and what most small independent Mac companies do. The only problem is that if you’re right out of college you won’t have many connections (which is important, seeing 99% of our work is from referrals) and a lot of people don’t want to hire contractors with no experience.

To get venture capital you need to have a great idea that needs lots of people and money, and you need to be willing to give it up to the venture capitalists. I don’t know of any Mac companies that went after venture capital.

The big advantage of staying in Tennessee (other than it being Tennessee) is that it’s cheap. And that’s very important when you’re self employed.

Expanding my ignorance

I’ve kind of ignored one last option you have, mainly because I don’t have any experience with it. That is, to go to work for a small Mac company (such as Panic, Delicious Monster, or the Omni Group). I don’t know how often they need to expand, and how many new graduates they can absorb and train. But it is an option.

Working for a small Mac company has the same advantages of being self employed in that you can concentrate on the Mac, but probably has the disadvantage of not paying as much as a large company could, and having to live where the company is.

Anyway, you have a few options to becoming a Cocoa programmer. I’m very partial to working for yourself, but that’s partly because of my previous experience with working for large corporations. YMMV.

Apparently, it’s official now: FreeHand is dead. (via Daring Fireball)

I knew it was dead back in 2003 when they laid off everyone (save a couple of people) on the core FreeHand team. They kept it alive for a while to do an updater with the few remaining people, then transitioned it off to India.

The somewhat odd thing was that the team knew FreeHand MX was going to be their last release. I remember a certain FreeHand engineer’s response to the question “why are you trying to cram so many features into this release?” as being “Because they’re not going to let us do another.” And to their credit, FreeHand MX was a return to their roots: vector based graphics program for print. At least from this observer’s perspective, it felt like FreeHand MX was the best FreeHand version in a while.

I’ve always had a soft spot for FreeHand, as I suspected most of my fellow Fireworks-ers did. After all, FreeHand and Fireworks were the only shipping products that were developed in the Texas office. Furthermore, Fireworks had been started by engineers from the FreeHand team.

Being so close in proximity, Fireworks and FreeHand often “borrowed” engineers from each other. When Fireworks was about to ship, we’d steal a couple of their engineers to help fix bugs. Conversely, FreeHand borrowed engineers from us, the Fireworks team, if they ever got behind. During the FreeHand MX cycle, I had the pleasure of spending about three months working on FreeHand, fixing bugs and bringing it up to par with the “MX” branding.

The most disappointing thing about FreeHand was Macromedia never let it live up to its full potential. After FreeHand fell behind Illustrator in market share, they pretty much ceded it. They had Dreamweaver and Flash, which were now their big money makers, and pretty much lost all interest in the print world. They kept trying to force FreeHand to be Flash, or to at least remake FreeHand for the web, instead of focusing on what FreeHand did best (print), and capturing that market.

Anyway, I digress. I’ve known for a few years that it was a dead product, but I’m still saddened to see that its official now.

P.S. Please note that FreeHand is the only product name with intercaps. i.e. Note that the F and H are capitalized in FreeHand, while in Dreamweaver and Fireworks, only the first letters are. This was a big pet peeve of the FreeHand team.

P.P.S As a technical aside, most versions of FreeHand (save the most recent ones) were written in a home grown language, that was humorously, and appropriately, called OOPS (Object Oriented Programming System). It was basically a preprocessor that generated C code that was then compiled to machine code.

Ever since I got here at Order N I’ve been wanting to develop our own product. It’s been on the back burner for quite a while (I’ve been with the company for over a year and a half now), slowly percolating. We’ve managed to generate a few ideas (127, to be exact) as far as products go, but we haven’t done anything with them.

At this point, I think we’ve got enough ideas, and we just need to pick one and move forward with it. The question is: which one?

I wrote up a process document on how to pick any idea (which is below), but I’m wondering if its the right way to do things. So I have a question to those of you have built your own product(s) (or are in the process of doing so): How did you decide what to build?

Did you simply build what you wanted to? Did you do research and find a product gap and fill it? Did you try to find the idea that you thought would generate the most money or the most users? Did an idea just hit you one day and you decided you had to make it?

My “process” for creating and picking an idea follows:

The purpose of this document is the establish a simple, lightweight process for coming up with and evaluating product ideas. The process should result in at least one idea that we can turn into a viable (read: profitable) product. The process is flexible and can be changed as circumstances change or as better ideas are introduced. The process evaluates ideas based on business factors, not engineering factors.

1. The first step in the product idea process is generating ideas (i.e. brainstorming). At this point in the process the ideas are vague and not well defined. The purpose of this stage is to generate as many ideas as possible, without evaluating them. The hope is that enough ideas are generated that a few of them are viable both engineering and business-wise.

Ideally, at the end of this step, we should have at least a few hundred ideas to choose from.

2. Second, after generating all those ideas, the next step is to whittle them down to a manageable number so we can do research on them. This will probably be between 10 and 20 ideas. By applying some simple criteria, we should be able to arrive at the top ideas we might be able to pursue. Ideally these criteria do not require research, but can be answered easily and quickly.

Criteria:

- What user problem/pain does this solve? If it doesn’t solve a problem, no one will buy it.

- How is the user going to pay for it? Or how does the product generate money? If a cool idea can’t generate money, its not worth it. A lot of Web 2.0 apps fall into this (like digg, YouTube, etc). They solve problems, but they don’t make money.

- What is the potential customer base? i.e. Is it consumer, professional, or developer level product? This will help rate the ideas –a consumer product is usually more valuable than a developer product since there’s potentially a larger customer base.

- Without architecting or engineering the product, is the product even technically feasible? If we’re trying to make cold fusion work, we should probably pass on that for now.

These criteria probably will not eliminate all but 10 or 20 ideas, but they should help us rank them and pick out the best 10 or 20 ideas. Some ideas might have to be fleshed out a bit more, but hopefully even vague ideas can be evaluated at this step in the process.

3. Next we need to research the top 10 or 20 ideas. This means fleshing them out a bit more so we can make more critical decisions about them. The research is targeted at finding out how much money the product might bring in, how likely we are to attract customers, and what building the product might cost.

What we need to know:

- How big is the potential customer base? This is an extension of what kind of product is it: consumer, professional or developer. Do a lot of people have the problem this idea is trying to solve, or is it a niche problem?

- What can we charge for the product? What is the competition charging? Not trying to determine final pricing here, but what is the range we could expect.

- How will we sustain income with the product? Upgrades, subscriptions, ads?

- Is there any competition? If so, who is the leader? What makes the leader, the leader? Can another product be sustained in this environment?

- What are the core/basic features in the product? We don’t need or want a feature spec here, just a general idea of what we’re providing. This should help with cost of building as well as what we can charge.

- What will set us apart from the competition? i.e. Do we think we can actually capture part of the market?

- What are the engineering costs in regards to time? i.e. how many engineers for how long? We don’t need a real number, just general estimates so we can compare it against the other ideas.

- What is the required infrastructure to make this work? This would obviously be bigger for web apps which need a large number of servers. Don’t forget about add ins to do try-before-you-buy or other demo schemes.

- What kind of marketing might we need to make the product a success? Mainly we want to know how expensive it will be to market the product.

- Are there legal or other expenses (like facilities or sales people or development software) that are required?

4. Finally, we need to evaluate the product ideas based on our research. Knowing how big our customer base is and how much we can charge will give us a ballpark of how much money the product could potentially bring in. The competitive analysis and feature ideas will give us an idea of how much of that money we might be able to get. The engineering cost estimates and required infrastructure costs will give us an estimate of the total cost to build the product.

So the basic “value” of the product idea is:

(Potential money in the market) * (Part of the market we get) –(Total costs of building product) = Profit

That’s real scientific stuff. Please don’t take it too seriously.

We’re not going to get hard and fast numbers out of this step, but it should give us a vague idea which idea is more valuable, business-wise, than the others. At the end of this step we should have at least one (if not more) idea that we can then take on to the product development process.

Once again, this is a light weight process that can (and probably will) change as we learn things. If you have ideas, suggestions, or comments about how to make this better, please let me know.

As you can tell, my process focuses on what product will bring in the most money. While money is good, I don’t want to build a product that I won’t enjoy working on.

What are your thoughts?