I Know Why The Caged Workspace Sings

Last week, I saw Alan Cooper speak at the patterns & practices Summit. Knowing I would probably get a chance to meet him, I went back to one of his books to brush up on my Cooperisms. The Inmates Are Running the Asylum is probably one of the best books I’ve read about product design, especially software. He provides insight on the common mistakes that software development teams make when building products. From feature overload to being so stubborn on schedules that you drop the most important aspects of the product, he hits upon the mistakes that seem so silly in retrospect, but are repeated over and over. .One of the best analogies for software pitfalls concerned the idea of doing things properly from the start to save problems later. He claims that if you were given 1000 bricks and asked to stack them one on top of the other, the way you place the first ones are vital to whether you will ever make it to #1000 (Jenga players out there know what I am talking about). Therein lies the danger of the prototype.

Prototypes are built to prove a concept and give people an idea of what they are going to get. What they should also be is a series of lessons to build the production-based systems as opposed to a code head start. Cooper talks about the deal to sell Ruby (the precursor to VB, making him the “father of VB”). He wowed Bill Gates with the prototype, which was subsequently purchased by Microsoft. He then proceeded to write the code from scratch, taking in the lessons of the prototype without persisting the mistakes that come with writing code the first time and shortcuts to “just make it work”.

When I look at Workspaces, I see a prototype put into production without a reset. The more I see some of the flaws causing the errors that are happening, the more I think that the design was done simply for the express purpose of proving that the concept works—not that the concept works with a broad set of use cases and performance requirements. Given there has never really been an official GDN team before, that’s no surprise. I confess that I’ve written applications before where it was my “night job” and I was so anxious to make it function that I didn’t have time to worry about making it work—the difference being that function means it gives the proper result at least once and work means that it gives the proper result every time. It’s why QA exists and that step was pretty much forgotten with Workspaces. Of course, none of my apps were as ambitious as Workspaces. As a prototype, you gotta admit Workspaces is kinda cool. But it might have made more sense to just re-write it as Alan did with Ruby. Although it’d be long overdue, that may be the only way to save Workspaces. It’s something we are considering and it would definitely take some time to do it right, but if we nail it, we can really change the game…

{Red Hot Chili Peppers - Californication}