I’m in the midst of crunch, so it’s been hard to keep up with anything outside of the work crunch world. We have around 2.5 weeks until the major milestone, which is more of a status milestone saying “this is what we have” than a deliverable. But it’s an important one, so we’re hitting the code hard. As such, updates may or may not be a little slow during that time.

Also, I read through a great book on visual thinking: The Back of the Napkin: Solving Problems and Selling Ideas with Pictures, by Dan Roam. If you’re looking to improve your communication with others, visualization thinking and communicating with pictures is a great way to do so, and Roam provides a great framework that enables anyone to improve their skills. I highly recommend it.

The trip was good, relaxing, and I hardly thought of events back home. I went back to work today with a fresh perspective and readiness I haven’t had in a while.

I read two books and got about halfway through on a third. One of the books I read was The Myths of Innovation, by Scott Berkun, who is also the author of my favorite project management book, The Art of Project Management.

In The Myths of Innovation, Berkun looks at the history of innovation, including the software world (he worked on Internet Explorer in the 1990’s), to reveal how ideas truly become successful innovations. It was a great read, and I especially appreciated Berkun’s framing of innovation in the context of the history of the world and all the great minds and companies that have been considered innovators.

I’m sure in the future I’ll have more to say about this book, and I plan on reading it again at some point so I can take notes. One paragraph in particular stood out to me, though, so I thought I’d share:

The best advice I’ve read on starting creative work comes from John Cage, the most innovative composer of the 20th century, who said, “It doesn’t matter where you start, as long as you start.” He means that there can be no perfect beginning: it’s only after you start – no matter how roughly – that you can evaluate and build on what you’ve done, shift directions, or start over with the insight and perspective you’ve gained in the process. Innovation is best compared to exploration, and like Magellan or Captain Cook, you can’t find something new if you limit your travels to places others have already found.

My curiosity piqued, I decided to check out the Chandler Project again to see where the team was at and if they were realizing their goal in any way to be groundbreaking. I even checked out the Chandler Hub, but I was disappointed in that it seemed more like a task manager than the desktop version appears to let on. I haven’t downloaded the desktop version yet.

I think the whole Chandler Project is a good lesson in the dangers of software development ambition. They started the project six years ago with a grand vision and true potential, but with every passing day the project falls further behind the innovation curve. Other companies have entered the fray of innovative approaches to Personal Information Management, including the beast of all beasts, Google with iGoogle, GMail, Google Calendar, and so on.

This isn’t to say the Chandler Project is completely doomed – yet. But their days may be numbered. And worst of all, it isn’t because the vision was too grand, but rather because the grand vision’s development wasn’t managed well enough to make it achievable. That’s the lesson to be learned: grand ambitions are great, but they better be managed.

What do I mean? Well, the Chandler Project team spent too much time focusing on the perfect design, and the perfect data structure, and the perfect process instead of focusing on what’s important: the value the product provides to the end user.

If it sounds simple, that’s because it is, if you’re willing to change your mindset. In my mind, the Chandler Project team fell into the trap many great technical beings like to fall into: building the perfect system.

Many times the rationale is that the investment will pay itself off in the long run, and that may be true, but if it takes 7 years to invest in the perfect design then that software system probably needs to last 20+ years to make the investment worth it. What percentage of all software systems designed do you know that have lasted 20+ years?

I am of course being facetious, but there is a broader point here. If we as software developers are interested in changing the world, providing value to customers, making an impact, or whatever-other-mantra-that-gets-your-juices-flowing, then our focus has to be on that mantra. We can’t be focused on creating the perfectly designed system but rather focusing on the capabilities and features that add value and solve problems for our users.

I’m only three chapters into the book, but it’s interesting enough. Lots of anecdotes to the wisdom of Fred Brooks’ Mythical Man Month, of which I am a fan. I’m already seeing some red flags early on in the project’s development – big scope, little incremental goal setting, smart people but possibly a lack of strong leadership. But then, I’m only a few chapters in.

Out of curiosity I went to the Dreaming in Code website, which led me to the Chandler website, only to find that it still hasn’t reached 1.0 status 6-7 years after it started. It looks like they have a lot of the same team intact, although Mitch Kapor is listed as an alumni of the project. In today’s world six years for this style project is an eternity. I look forward to learning about the rest of the story.