Mike Coyle’s Weblog

We just posted a new video, ProjectPipe in Under 2 Minutes.

Check it out. It’s largely comprised of the best “action sequences” from the ProjectPipe 101 video.

We’ve just released the transcript to the ProjectPipe 101: Concepts and Features video.

I’m sure that I turned away some potential viewers by mentioning up front that it is 20 minutes long. That’s a huge time investment for most of us. But then again, I’m a big fan of truth in advertising

If you’re pressed for time, I’d take a look at the transcript first. It should give you a good sense of what the video covers. The transcript also has the start times for each topic, so that you can jump around from topic-to-topic if you prefer.

Also, the video is encoded for progressive download in Quicktime. Even though it’s a large file, it starts playing almost immediately.

We wanted to get a single “umbrella” video published that covered the breadth of what ProjectPipe has to offer. I tried to walk through the subject matter at the cadence and level that I’d cover in a one-on-one meeting over coffee at Starbucks: More detail than a multi-person conference room sales call, but less detail than a formal training video would provide.

Going forward, we’ll be producing much more topic-focused content in much smaller chunks.

]]>

ITConversations recently published an OSCON 2005 session by David Heinemeier Hansson titled Secrets behind Ruby on Rails.

Even if you’re not a Ruby developer (which I’m not at the moment), this podcast episode is 16 minutes well-spent. In defending his position that “flexibility is overrated”, David makes the following comment:

“Too many technologists are chasing flexibility as thus it was free. It is not.”

Amen.

There’s no shortage of developers and architects who not only err on the side of configurability and/or future-proofing, but cut the wheel and swerve hard in that direction. My counter-arguments and counsel have traditionally drawn upon the Extreme Programming credo of YAGNI (You Aren’t Gonna Need It), and the Zen of Python, among other software writings to complement my first-person experiences. The rapid adoption and success of Rails provides additional points of reference that are well-grounded not just in theory, but in the heads-down, pragmatic implementations that moves our craft forward.

Even if you are not working on a Rails project, there are software architecture lessons to be learned from the successes and challenges that the Rails community faces as it moves through its adolescence.

I like to make the analogy that application architecture is much like a skeleton. It’s comprised of bones and joints. Bones are the well-defined elements of the application, the behaviors of the application that are well-understood, and therefore can be built rigid and strong. Joints are the points of flexion, accounting for uncertainty and/or future change either through dynamic behavior or external configuration.

IMO, the challenge of good software architecture lies in the proper layout of bones and joints in building the skeleton of your application.

If you have too much bone and too few joints, your architecture is unnaturally rigid, and making change involves literally breaking a bone and then coding your way through its repair.

Conversely, if you have too many joints and too few bones, your application will not have enough internal structure to stand on its own. Now your application probably needs to lean on an XML Configuration-based walker just to stand upright. It doesn’t get much less agile that that, metaphorically speaking.

The other issue that frequently arises is the misplacement of flexion points, making the application flexible in areas when far simpler solutions would suffice, and hardcoding specific behavior where flexibility is genuinely useful.

The classic example of misplaced flexibility is the case where an architect in a solid 100% Oracle (or 100% Microsoft) shop designs a complicated and opaque “data abstraction layer”, so that the application would require minimal changes in the event that the company nullifies long standing enterprise vendor relationships at some point in the future and forces the migration of all legacy applications built atop database vendor A to now run atop database vendor B, and the company chooses to not leverage such a seismic event to refactor, rewrite, or retire said application. In this example, the codebase is encumbered (and a chunk of the budget depleted) in the interest of building functionality that addresses a risk that is very, very unlikely to materialize.

If you’re that forward thinking, you might as well code your application to be flexible enough to address the Y10K Bug

By treating your application architecture as a skeleton, you will hopefully be able to put flexibility in your application where it makes sense, and reduce the risk that well-intentioned but misplaced flexibility becomes a skeleton in your application’s closet.

P.S. While some may consider the previous sentence to be a mixed metaphor, I disagree. Given the “Web 2.0″ world in which we’re living, I prefer to think of it as a Metaphor Mashup.

We’ve posted our first screencast. It is titled ProjectPipe 101: Concepts and Features.

The video is in Quicktime format.

Running just over 20 minutes, it covers most of the key ProjectPipe features, including:

• Tagging Support
• MS Project and Excel Integration
• Dependency Visualization
• Integrated Change Management (between Subversion and the Issues List)
• RSS
• Role-based Security
• Configurable Templated Content

Check it out. If the video piques your interest, we have Free and Paid accounts available, and you can be up and running in less than a minute.

I’m in the process of doing post-production on a 15 minute screencast that provides a walkthrough of ProjectPipe. It should be available on Monday.

I’m using Camtasia Studio, the screencast tool developed by TechSmith. Far and away the most impressive Windows app I’ve used in a while.

Note: As we mentioned last Friday, we’re going to try and post some lighthearted content on Friday afternoons to peruse when planning your weekend. Please note that all of the references in the Top 10 list are fictitious, most of them obviously so.

Last week’s inaugural Hawaiian Shirt Gonzo Friday Top 10 List was a lot of fun. But we found ourselves in somewhat of a moral dilemma: How can we position ourselves as champions of agile delivery, flexibility, and simplicity to our customers, while still remaining beholden to the conformist and somewhat archaic notion that a Top 10 list must contain 10 items.

After nearly seven days of research, I’ve come to the realization that one can capture 96% of the humor with just 70% of the list items. That saves you, my dear reader, from the long and burdensome slog through those three superfluous Top 10 items whose very being epitomizes the Law of Diminishing Returns.

Imagine that, a Top 10 list that’s 30% lighter. Anyway, here we go:

Hawaiian Shirt Gonzo Friday Top 10 List #2:
Our 7 Biggest Disappointments In 2006 (so far)

2006 has been a good year so far. We have a bunch of ProjectPipe users all over the world, and our website and blog traffic continue to grow at a nice clip. Plus, we have some new functionality that will make ProjectPipe much more customizable. I’d also like to thank those who’ve given us constructive feedback.

Unfortunately, there were a handful of dissapointments as well. The Yan to our aforementioned Ying. As painful as they are to recollect, here are our Top 7 Biggest Disappointments:

7) Walt Mossberg’s Review: “It’s like Flickr, but without all of the pictures”

6) Everyone missed our Superbowl ad depicting Abe Vigoda as the new frontman for Phish.

5) Our worst fears from last week’s list have materialized: We’ve been characterized in the mainstream media as mean and judgemental for the inclusion of Role-based Security and Auditing respectively

4) The minor altercation with Nintendo’s Mario, because no members of Cartoon Plumbers Union Local 123 were involved in the creation of the ProjectPipe logo.

3) Stephen Colbert still holds to his schedule of making Pennsylvania’s 13th district (The Fightin’ 13th) the 434th installment in his 434-part series “Better Know a District” on The Colbert Report. Based upon my calculations, that could take…..months of sitting through shows about far lesser districts before it finally airs. Stephen, you’re on notice!

2) We got an email from Fred Brooks last week advising us to add about 20 developers to hit our 2/28 release. That’s not a good sign.

1) We know that Joanie Loves Chachi, but evidently not enough to buy him a ProjectPipe workgroup subscription for Valentine’s Day.

Have a good weekend,
Mike

When we set out to build ProjectPipe, we were originally looking to bring lightweight nouvelle Artificial Intelligence (AI) to the discipline of agile IT project management. We had some cool demos and prototypes that we shared with a small group of people that we trusted. Nothing earth shattering, but content interesting enough to compel us to spend most of our free time pursuing our vision and ultimately quitting very good full-time jobs to make a run at launching a software startup.

Fast forward to the actual release of ProjectPipe in December, and none of the functionality that we initially prototyped and shopped around to friends and colleagues is present in the user-facing elements of the application. Some is still in the Proof-of-Concept stage, some of it is teed up for future releases, and some of it is leveraged behind the scenes, but none of it is visible to our growing user community.

To a certain degree, we set out to build product A, and ended up shipping product B.

It turns out that this is not all that uncommon. Paul Graham spoke about this phenomena in his presentation at StartupSchool, which he subsequently published in his essay titled Ideas for Startups.

So just as our original product vision evolved, so has our vision of our target market. Originally, there were two profiles that made up our view of our centerpoint customers:

• The “Alpha Dog”, or technical architect/PM that leads corporate IT projects
• The Independent contractor that is often the Project Manager, architect, cook, and bottle washer for smaller projects and/or sidework

It’s recently become evident to us that the feature set of ProjectPipe is also useful to a third market: The (drum roll please) Web 2.0 Startup.

[TODO: Blab about the fact that we’re a startup ourselves, and mention the bit about “eating our own dogfood” for the umpteenth time]

There are a bunch of things in ProjectPipe that we’ve found useful in spinning up our company. Here’s a sampling:

• Most small businesses incorporate some form of To Do List to coordinate their day-to-day activities. ProjectPipe’s Issues tool works nicely for this. It allows you view items either in a flat list or as a hierarchical outline. It also provides assignments and prioritization. Plus, you can also subscribe to a secure RSS feed, so that you’re notified when an item is completed by another team member.
• Subversion is a no-brainer if you have source code that you’re developing as part of your startup. But it also comes in handy for other files that you’d like to work on locally, yet keep synchronized across 2 or more machines. I can see the ad now: Subversion: It’s not just for source code anymore.
• ProjectPipe’s Document Management capabilities allow you to edit documents from within a web browser, or upload existing documents or images. We actually use Subversion for most of our Document Management, since Subversion-managed content is readily accessible offline. But the Document Management tool is still real useful in its own right, and it’s integrated with one of our upcoming collaboration-based features. Stay tuned for more on that topic…
• Lastly, ProjectPipe’s Notes tool is convenient for outline-based notetaking. It’s probably no big secret at this point that we’re huge fans of outlining. While our web-based Notes tool isn’t quite as as fast as a desktop outlining app such as OmniOutliner, it’s more than responsive enough for most uses, unless you’re taking live dictation from the president of the New York Speed Talker’s Society after he shotgunned a Quad Shot Iced Espresso with a Red Bull chaser.The hoisting capability allows you to narrow down your focus to a specific topic while still keeping all of your content in one taggable, RSS-enabled basket.I’ve used the notes tool everywhere from boardrooms to Wi-Fi enabled bookstores. It works quite nicely.

In closing, we’re starting to market ProjectPipe to web startups. We’ve created a new Google Group to support a community of users that are leveraging ProjectPipe for their startups or small businesses. The group is named projectpipe-smallbiz.

If you have any thoughts regarding how you’d like to use ProjectPipe for your startup or small business, please join the Google Group and/or drop me a line at mcoyle@botonomy.com.

Oh, and if you are still looking for that “Killer App” to justify gobs of VC funding for your very own Web 2.0 startup, here’s a veritable treasure trove of ideas.

Note: We’re going to try and post some lighthearted content on Friday afternoons to peruse when planning your weekend fun. And if you’re not careful, you may learn something before it’s done!

In building out the underlying application infrastructure for ProjectPipe, we added a bunch of features that seemed like the right thing to do at the time.

Here are the Top 10 features that we added to ProjectPipe but maybe shouldn’t have:

10) We came up with a lightweight mechanism for integrating web-based apps and desktops applications. I spoke about this approach here. Unfortunately, now that AJAX-y Web 2.0 applications are all the rage, far fewer people are using Excel, Word, or MS Project anymore, especially in business.

9) We baked Tagging into our infrastructure, but the profound lack of interest in Flickr,
Gmail, and del.icio.us suggests that people may not find Tagging to be a particularly flexible or intuitive means of organizing their data. Someday if Amazon were to support tagging, maybe it would catch on.

8) We allow data to be managed as an outline, and we support hoisting so that you can focus exclusively on a segment of the outline. For example, you can hoist your view of the project plan tasks so that you only see the tasks for Iteration 2 of the Elaboration Phase. But deep down inside, we feel a little guilty that our innocent hoister may be missing out on the big picture. For if you focus on the 20 tasks that you’re working on, you miss out on the majestic view that you get as you stand and look out over the 500+ line items of the overall project plan, most of which you may never otherwise be involved with. From that perspective, the stuff you’re working on today looks like a little dot.

7) We allow users to subscribe to adds/modifications/deletes of any data via RSS, but our feeds are guarded by the Role Based Security. However, if you have to type in a userid and password, is it still Really Simple Syndication?

6) We’ve hooked auditing into the application. But if someone on your project team wants to delete a reported bug when no one is looking because it’s hard to fix, who are we to judge them?

5) We provide Role-based Security, but it seems kinda mean to not give everyone on the project the same access privileges.

4) We have integrated workflow. But that was no mistake, my friend. Workflow is the cowbell of enterprise computing. Even though workflow means different things to different people, you just can’t have too much workflow. Guess what? I got a fever. And the only prescription… is More Workflow!

3) We allow any-to-any links to easily establish traceability across use cases, requirements, test cases, issues, etc. However, it’s probably easier to just keep track of all these dependencies in your head. I think that’s the approach that the GTD folks advocate. (I tried speed reading the book). Plus, committing these dependencies to memory instead of entering them in a system means less typing, so not using this feature is also easier on your fingers.

2) We’ve integrated visualization tools that automatically layout complex traceability graphs. But Good Developers know that Project Managers don’t need dependency diagrams. Seeing the big picture without first spending hours pouring through all the excruciating detail is like having dessert before dinner.

1) We made it possible to dynamically alter the data model by adding fields to existing tables and/or creating entirely new tables. But who ever heard of a customer wanting to customize an application? Not I, for one.

Have a good weekend,
��Mike

]]>