Christian Simms’s Weblog

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!

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

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.

Jim summizes the lousy in-house tool situation with his boss, and his boss agrees that it’s a shame.
When Jim asks if the company could pay for a hosted provider, his boss just
chuckles. Jim’s boss tells him that the project’s budget has already been set for the next three months, and
the time to get a purchase through accounting takes ages, but
if Jim personally pays for it that he could be reimbursed later from another budget area.
Having been burned in the past at other companies with unreimbursed expesnses, Jim sends a follow-up email to his boss
summarizing their conversation and cc’ing the business sponsor. The business sponsor sends Jim a private follow-up
email thanking him for taking initiative and saying he’s really looking forward to having a shared system so that
he and his direct reports can see how development is going.
Stated that way, it gives Jim the shivers, but he’s happy he got some brownie points.

So Jim ponies up for 1 month with ProjectPipe on his personal credit card.
He likes the fact that his user id is his email address - one less thing he has to remember.
He gets the login email in less than a minute, and immediately logs in.
The first thing he does is go to the team tab and invite his QA and developer guy. All he has to do is enter
their name, email address and role, and they’re automatically sent emails telling them how to login.

As soon as the team receives the invitation emails, they jump to work.
The developer imports the current cut of source code into the project’s Subversion repository, he wants
to play with it for a little while before moving the offshore guys to it.
Meanwhile, the QA guy imports the bugs from the most recent spreadsheet into the web app.
Since there are only a handful of bugs at the moment, he’ll just manually copy + paste them into the app,
but if there were a lot he could have used the small ProjectPipe client program to upload the data from
a spreadsheet (editor’s note: assuming Christian finishes that functionality).

While his team is busy adding data to their project, Jim installs the client program because he wants to upload
his MS Project plan into the web app. He probably would not have shared the project plan with the team
(he gets tired of developers nitpicking task timeline details), but since the business sponsor had talked
about it, he figures it’s better to be open and critized than quiet and fired later. Actually, Jim gets a little
happy (not too happy, he *is* a PM after all) thinking how he can CYA by saying that the entire project
plan and its status was always available to everyone on the team.

Jim reads up on how ProjectPipe integrates with MS Project, and is happy.
He wants to keep his .MPP file safe and local
and doesn’t want any program messing with it. He remembers the time when a BA took his 5,000 task project,
and ran Resource Leveling on it but didn’t tell Jim until he asked why the project had moved out several months
past deadline. Anyway, the ProjectPipe client is totally unobtrusive, after it asks for his email address,
password and project name, it just sits quietly in his taskbar. Its interface is through the web
(Jim wonders how they did that, but doesn’t much care that under the hood it’s using the XMPP/Jabber protocol,
as long as it works), so to import his project all
he does is go to the project tab in the website, click “Upload project to server”, select his file and click Upload.

To be continued…

Here’s a question I get sometimes: why would anyone pay for your product? If a project manager already has MS Project
and other software which is supported by their IT organization, why should they pay for anything else? And it’s true: if you’re
happy with the tools you have, then you don’t need us. But let me give one scenario where I think our product makes sense.

The project has been limping along for three months now, and the last PM (project manager) Larry
just quit because he got tired of suffering through long meetings with upper management trying to explain why the project was behind schedule.
It had started promising, like most projects do. Two weeks into the project, he and the BA (business analyst) had finished scoping out the project
and requested six developers for six months — they knew six good developers who were rolling off another project down the hall.
It wasn’t Larry’s fault that that their request was “modified” into six offshore developers.

Meet Jim, the new project manager. As a condition of taking the position, he got one developer and one QA guy working locally
to augment the offshore team and to provide him some local expertise on the project.
He also wanted to have an independent assessment on how the remote team was performing.

Jim’s first day on the job, he encounters his first stumbling block. The offshore team uses
MS SourceSafe for their source control system,
but their setup requires a VPN to access over the internet.
Jim’s developer needs to install the VPN software to compile the latest source
code, but Jim’s IT department refuses to let him install it because of cross-network security concerns.
One potential solution that Jim explored but rejected was installing the source code repository locally, and then having their offshore developers
use this repository remotely. But his IT department said it would take at least a month before they could provision
a new server, install it in their data center, install the software and get it running through their VPN.
Jim didn’t want to do what Larry had done, which was rely on the offshore team to periodically send him releases, because
Larry said that most of the time the releases didn’t initially work right. Whenever he would ask for a fix for a release, the offshore team
would always say that the release they had wasn’t worth fixing because it was terribly out of date,
and a new one was coming Real soon now.

Jim will try anything once (ask him why he doesn’t drink Tequila anymore), especially if he has no other options.
So he does a little research on the Internet to find
a hosted version control system. He finds that there are a large number out there, depending on what kind of repository
you want. Jim’s developer has been telling him that Subversion is an up-and-coming
version control system that is a replacement for good old CVS. And Jim’s developer
is begging him to switch from MS SourceSafe. The offshore team has worked with several version control systems in the past and doesn’t care.

Jim’s second day on the job, he encounters his second stumbling block.
On Jim’s first day, he had asked the QA guy how bugs are tracked on the project. Since the QA guy was new to the project,
he said he would get back to him. Today, the QA guy breaks the news that the team had been using a spreadsheet
which Larry and the offshore team had been emailing back and forth daily. That worked OK when there was no QA locally.
But now that development and testing would happen locally, they needed a shared issue tracking application.
The offshore team only has an internal issue tracking application which wasn’t designed to be shared over the internet.
So Jim goes to his IT department again, asking if they could setup an issue tracking system for him. They give him the same old
song-and-dance that it would take at least a month, but maybe even longer if they would have to buy and install a commercial
issue tracking system (there aren’t that many good free/open source issue tracking applications).

Jim goes back to his research on hosted Subversion providers. He finds that there are a handful at the moment, and that several also offer
Trac, a free issue tracker and project management tool. Trac looks
great for small projects, but Jim has been doing project management for years and doesn’t consider issue tracking to be project management.

Out of all the hosted Subversion providers, Jim only finds one that offers him
issue tracking and project management in a way that he’s used to. Stay tuned for what he does next…