The seven most important questions for any project

After some reflection, I realized that there are seven questions that need to be asked before you start on any project. While you may ask yourself a subset of these questions, it is critical to answer (or at least think) about all of them before writing a line of code.

Each of these questions has a direct impact on how the project can be engineered and what tools and techniques you use to engineer it.

1) “Problem?”

That is, the need are you trying to fill. Are you trying to save people a few minutes when typing of a document? Are you making a user interface easier to use? Are you providing control software for life support on Mars? Are you trying to give a bored person something to do for ten minutes?

Starting with a solution statement is almost always a recipe for disaster. Find out what the problem is that needs fixing first before committing to a solution. I have found that by asking what the problem is that actually needs solving, you can radically reduce the complexity of the answer.

2) “Target audience?”

Who are you trying to solve the problem for? Are you trying to solve the problem for your coworkers? For ten million people? For a surgeon in the middle of surgery?

Who your target audience is helps to determine how much polish you need to put on the product. A solution that is acceptable for your coworkers is going to require a lot less work than something to be used by a surgeon. (Unless, of course, you work in a hospital!)

3) “Time to market?”

Simply put, how long you have before the solution needs to be in place. Today? A week? Six months?

The solution to a problem that needs to be solved today is inherently more limited than one that can be solved by next week or next year. Sometimes a problem can’t be solved in its original form in the time frame required. In that case, you need to reduce the scope of the problem or increase the time frame.

4) “Headcount?”

The more people working on a problem, the larger the scope that you can handle. More people also means more communication, more up-front design, and more time needed to handle changes down the line.

5) “Budget?”

Budget can refer to both money as well as (existing) equipment and tools. If you have adequate equipment, you may not need a monetary budget over what is currently allocated. Sometimes, having a monetary budget means you can buy a solution off the shelf and reduce your overall time and effort to solve.

6) “Licensing?”

This means how are you going to sell — or not — the final solution. If you are solving a need for existing customers, is it part of a patch to the existing version or is it to be released in the next major version? Are you giving it away? Are you going to be using a pay-per-use model?

A solution for one licensing model may not work for another. It’s important to be clear up front what you’re going to do so that you don’t end up wasting everyone’s time.

7) “Return On Investment?”

This is perhaps the most open-ended of all of these questions. In a nutshell, how much value will this project give to you and your target audience — is it something that will save some infrequent annoyance, or is it something that will transform lives? The more impact it will have translates directly into how much more you can invest before hitting the break even point.


RSS and OS X Mountain Lion

I made the jump yesterday, and discovered to my (unhappy) surprise about how Mountain Lion now handles RSS.

Or, more precisely, how it *doesn’t*. RSS is no longer supported in either or in Safari.

After reading a bit, I decided to try out Reeder. Nice program, but it has an unfortunate (fatal) flaw: It doesn’t import RSS from

Since I happen to be good with the command line, I shortly came up with a method to extract the RSS feeds. This is a 90% in that the results that it prints have some encoding (such as & for an ampersand.) I’ll post later a 100% solution.

This solution may or may not work with Safari RSS feeds. I’ll post if I see a solution for Safari.

To extract your RSS feeds:

  1. Run (or any other command line terminal). can be found under your dock at: Applications -> Utilities ->
  2. Make sure a terminal window is open. In, the following menu option will open a new terminal window for you: Shell -> New Window -> Basic
  3. Copy and past the following into a terminal window:
find ~/Library/Mail/V2/RSS -name "*.plist" -print0 | xargs -0 grep -hA 1 RSSFeedURLString | grep "<string>" | sed -e 's/.<string>//' -e 's/<\/string>$//'

You’ll now have a list of RSS feeds. Enjoy!


Edited to fix accidental change in the command line.

Would the real imaginary number please stand up?

Well, you’ve may have heard about imaginary numbers. There’s one problem: They don’t exist. Not really. That’s why they are called imaginary numbers. Real numbers, by contrast, do exist. You can put your hand on 2 apples. You can’t put your hand on an imaginary number of apples (unless you’ve had some mind-altering drugs, but that’s another story altogether.)

Continue reading

To Infinity (and beyond!)

Infinity is not an intuitive concept for most people. My favorite example is the magician with the inifinite hat:

Boffo the Impossible has an amazing trick. Starting at 11:00 am, Boffo puts two balls into a hat, and pulls one out. Every time he gets half-way closer to noon, he puts two balls in, and takes one out. So, at 11:30, he puts two in and takes one out. At 11:45, he puts two in and takes one out. At 11:52:30, he puts two in and takes one out. And so on — he becomes an flurry of activity as he gets closer to noon. At noon, he stops.

The question is: how many balls are left in his hat at 12:01 pm?

Continue reading

Unix filesystems for Windows people

In the Unix world, there are no “drives” as per Windows “c:\”, “d:\”. There is only a single top level directory known as “/” or “root”. This doesn’t mean that you can’t read floppy disks, have second partitions, second hard disks, etc.

Continue reading

Dev vs. dev

Hi all!

I wanted to add a quick note about why I chose the name “” for the name of my tech/math blog. I chose it because it has a dual meaning — depending on which side of the Unix/Windows debate you fall upon.

(All trademarks are owned by their respective owners.)

In the Windows/Microsoft world, dev is an abbreviation for developer, development, or development work depending on context.

Under Unix, dev is where device files (pointers to anything that isn’t a file) are stored. More about what this means later.