Safe from the Losing Fight

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?

Recently Brent Simmons posted his thoughts about large cocoa projects, which elicited a lot of responses within the Mac programmer community about what makes code easier to “research.” There’s a lot of good stuff there, but I wanted to focus on one facet of the discussion that was brought up, namely NSNotificationCenter.

First, anyone who has read the Design Patterns book knows that NSNotificationCenter is the observer pattern. It is useful for decoupling objects, in which is a good thing, because it makes classes more reusable (because they have fewer dependencies) and more maintainable, because, if done correctly, it insulates changes in one class from another class. These are all good things, and observers are good, and you should use them.

The problem comes up with Apple’s implementation of NSNotificationCenter, and I’ve often wondered why they chose the implementation they did. There are a few problems with it:

1. As noted by Michael Tsai, NSNotificationCenter is a singleton, and thus essentially is one big honkin’ global. Globals are bad ™.

2. NSNotificationCenter allows a many-to-many relationship between observers and their subjects. That is, many different subjects can send the same notification, and several observers will listen for the notification, regardless of the sender.

   This breaks the observer pattern, which was intended as a one-to-many relationship, because it breaks the idea that the observer observes the subject. Instead it produces the idea that the observer observes the notification, which is wrong. The notification is simply a convenient way to pass information between classes, it is not really a part of the relationship between the subject and the observer.

3. The syntax of using NSNotificationCenter puts the notification center as the receiving object, and thus puts the focus on the notification center, instead of focusing on the relationship between the subject and its observer.

These problems are compounded by the fact that just about all sample code that I’ve seen, from Apple and others, use NSNotificationCenter in the many-to-many relationship, instead of a one-to-many relationship.

Of course Cocoa uses another design pattern that can be used as a stop-gap for the observer pattern: delegates. Delegates define a simple one-to-one relationship between the subject and its delegate. It has the benefit of being easy to implement and clarifying the relationship between the subject and delegate. The problem is, it’s not appropriate for the observer pattern, for a couple of reasons:

1. As the name implies, a delegate is delegated tasks or decisions. That is, a subject is dependent on the decisions a delegate makes, and will change behavior depending on if, and which, delegate is attached. This is the opposite of an observer pattern. The subject does not care who is listening, or if anyone is listening at all. The observer, however, will often change behavior or take action, depending on what the subject does. In other words, the dependency is modeled in the exact opposite direction in the delegate pattern.
2. The delegate pattern is a one-to-one relationship, but the observer pattern is a one-to-many. It makes sense that a delegate subject would only have one delegate making decisions for it, but it doesn’t make sense that an observer subject can only have one observer listening to it.

Still, you can trivially implement a one-to-one version of the observer pattern using the same technique as implementing a delegate. You just shouldn’t call it a delegate because you’re implying the wrong direction for dependence.

All this said, there’s a much better way to implement the observer pattern, which I’ve seen in just about every other framework I’ve used. Things get a little tricky in Objective-C because the lack of multiple inheritance disallows use of mix in classes. However, it can still be done. Essentially you’d need two classes: ObserverSubject and Observer.

ObserverSubject maintains a list of Observer objects that are listening to the subject. It has hidden methods, called only by Observer, for connecting and disconnecting interested Observers, and a notify method for the actual subject to notify all listeners that an interesting event has happened.

The Observer class maintains a list of all ObserverSubjects that it is currently listening to. This is for the express purpose of automatically disconnecting from them when the Observer object is destroyed. The main method on the Observer class is called watch, and connects the Observer with the Subject. The Observer class also keeps a pointer to the actual observer, which it forwards all notifications to.

A simplified example of how these classes would be used:

@interface MySubject {
}
- (ObserverSubject*) subject;
@end

@interface MyObserver {
}
- (Observer*) observer;
@end

MySubject* mySubject = [[MySubject alloc] init];
MyObserver* myObserver = [[MyObserver alloc] init];

[[myObserver observer] watch:[mySubject subject]];

In this design, the one-to-many relationship is enforced, and the syntax puts the focus on the relationship between the subject and its observer. Also note the lack of globals.

In conclusion, observers are a good thing, and you shouldn’t write them off just because Apple did a shoddy job of implementing them. Modeling simple one-to-one observers is trivial to implement, and modeling a true one-to-many observer pattern isn’t all that difficult either.

In my previous two Core Image filters, I attempted to make the minimal amount of changes to the project template in order to make them work. It turns out I was a little too minimalist.

If only one of the previous examples is in your Image Unit folder, then everything works fine. The problem comes in when you have both of them in the Image Unit folder. In that case, neither show up in the UI. The problem is Core Image cannot uniquely identify the filters (i.e. it thinks they are the same, and gets confused.)

At first, I thought I just needed to add a unique bundle identifier to my Image Unit package. Unfortunately, that is not the case, which makes sense because you can have several filters in one Image Unit package.

The problem lies in the Description.plist. From the template, there are three keys which have the value “MyKernelFilter”, and one key which itself is “MyKernelFilter.” Two of the values and the key need to be changed to something unique.

If you look under the first key in the Description file, CIPlugInFilterList, you’ll see a dictionary of filter descriptions. You’ll note that in my examples, such as the HSB Mixer, I left the key for my filter description alone, as MyKernelFilter. I need to change it to be unique, like so:

...
<key>CIPlugInFilterList</key>
<dict>
<key>HSBMixer</key>
<dict>
...


Now that I’ve picked “HSBMixer” as my unique key, I need to replace MyKernelFilter with it in a couple of places, namely the CIFilterClass and CIKernelFile values. So at the bottom of the Description file:

...
<key>CIFilterClass</key>
<string>HSBMixer</string>
<key>CIHasCustomInterface</key>
<false/>
<key>CIKernelFile</key>
<string>HSBMixer</string>
...


CIHasCustomInterface didn’t change, I just left it in there because it was sandwiched between the two values that I did change.

That should cover it. If you rebuild and add both of the examples to your Image Units folder, they will both show up. This is pretty tedious work, so in future posts, I will just assume this is known and skip over it.