csimms.botonomy.com

Ian Landsman’s 4 Rules for the Practical Entrepreneur

Ian Landsman just wrote a great little piece outlining

4 criteria to evaluate a new product against

. I’ll take the bait and evaluate our new product in this context.

1. Fragmented Market

Pass - I’d say that the project management thru-the-web market is highly fragmented without one clear dominant vendor yet.
The desktop project management market is dominated by Microsoft, but we’re not competing with them
– rather, we complement them by integrating with them.

2. Business Before Consumer

Pass - we’re only targeting business. I can’t even imagine what a consumer-oriented multi-person project is.

3. Clear and Simple Revenue Model

Pass - we have a really simple table summarizing
our prices and product options.

4. Dog Food

Pass - we’ve been using our own stuff for a while now. And it really is great advice
– when we initially cut over to using our system, we found a bunch of bugs and missing features.

In summary, we pass all 4 rules!

Hello World

One of my favorite SpongeBob episodes is Procrastination (sorry just a mediocre link),
where SpongeBob has writer's block. He stays up all night putting off writing a short essay for Mrs. Puff, with the pressure building
the more he procrastinates, even going so far as to have Dali-esque nightmare of sleeping past his deadline.
(SPOILER: Yes he finishes his essay on time, but Mrs. Puff had cancelled the essay and didn't tell SpongeBob.)
I'll be honest and say I feel the same way trying to write my first blog entry. Taking the plunge anyway...

I promise you'll get:

1. Fresh content every working day from me or Mike.
2. A little humor in all my posts.
3. Something educational in all my posts.

Mike and I have developed a really easy to use hosted project management application.
We're going to open it to the public real soon now -- the private beta is just about over. We got some good feedback (thanks people!),
fixed a bunch of bugs and kept adding features.

Yes, the project management application space is crowded. However, crowded does not necessarily mean all niches have been filled.
You have the low end covered by such sites as Basecamp, which aim for short and small
projects such as web design. If you have a MS project plan with a thousand tasks, they're not going to be helpful to you. And on the
high end, you have such "enterprise solutions" as Project.Net and eProject.
And when they say enterprise, they mean: no price quotes online (you have to negotiate, where the bigger the company the bigger the discount),
"on demand" means you wait for them to get back to you, and the feature set is described in hazy marketing literature.
But please understand, each company I just described has their own niche where their customers like how they operate.

Our product is a bit unique, we think that we have a good blend of the low-end friendliness and ease-of-use that people want, and the high-end
functionality that people need. We tried to design our application so that little or no training is needed to use it. We have two killer pieces
of functionality that I'll explain more in a later post:

1. Two way integration with MS Office (including MS Project).
2. Easy-to-use traceability.

Why Python?

Here's a question I get sometimes: why did we use Python? I had been programming in J2EE/Java for six years before ProjectPipe. I had used most of the major technology areas in J2EE: ejb, servlet, jsp, jms, etc. I had lead several successful projects that mostly used BEA's WebLogic app server (for a while it was the best J2EE app server), though I also used the JBoss/Tomcat combination as well (mostly during development because it was faster to reboot).

We're not the only people who have left J2EE for hopefully greener pastures. Bruce Eckel just wrote
an article about people leaving Java for Ruby. I left Java for Python. I left for two reasons: 1) my buddy Mike bugged me to look into Python and 2) once I got over the white space/indentation Python issue, I found my productivity is higher. It's difficult to compare your productivity when using two different technologies, because once you solve a problem using one technology, you've learned some things and it's easier to solve the same problem in a different technology. Anyway, the only concrete difference I can offer is that it used to take about a minute to boot up a J2EE app server, but I can boot up my Python app server in 2 seconds. If you consider that during development you might reboot a hundred times in a day (you usually don't have to reboot in either technology if you just change a web page), then you can see that you might lose 6000 sec (100 x 60 sec) or 100 minutes using J2EE vs. 200 sec (100 x 2 sec) using Python. Of course, when your app server is rebooting you might look over code, but on the other hand it's very distracting to wait an entire minute before you can test changes you just made -- you're just as likely to keep surfing the web an extra ten minutes while waiting for your app server to finish booting up. And since J2EE is so damn complicated, it's tough to write unit tests -- I've done it occasionally in J2EE, but you usually have to either test outside of J2EE or go to the trouble of setting up and using the Cactus testing framework. If you write tests using Cactus, you're still stuck with your app server boot time.

The Python community has a number of database and web frameworks available, but Mike and I chose
Twisted for our networking and Nevow for our web framework. We rolled our own database support (written on top of Twisted). Mike was the instigator to use Twisted -- it took a while to convince stubborn me to use it, but after looking around, I grew comfortable because the guys developing it are really smart, and their arguments on the simplicity and scalability of their async approach sold me.

I would say that the only major thing I miss from Java is the boost in performance you get with Java's excellent JIT (Just In Time) compilers that come with the JVM. A while ago in an old weblog of mine,
I made some simple performance measurements and found that Java with JIT is something like an order of magnitude faster than Python. Though I'm keeping my eye out on the PyPy project which is working on JIT technologies for Python (which is especially difficult because of the dynamic nature of the language).