Archive for the ‘Uncategorized’ Category

Best and Worst Collaborations

… or, a better title might be: “too much structure kills creativity”.

When I think about the best, and worst, collaborations I’ve been involved in with TeamCamp, the collaborations where we’ve ideated, prototyped and produced something, were by far the best. The richest collaboration was definitely on a web service we developed called Twegather. The idea was born from a problem that we personally experienced, and it allowed our diverse group apply our skills. We rapidly prototyped a service, from a quick and dirty MVP, to a full fledged service. We pivoted through three UI designs, and constantly innovated to make the service easier to use. Ultimately, we closed the service down because we really couldn’t see a way to monetize the service and we all got busy with other things. But it was an incredibly fun and rich learning experience and I never regretted a minute of it.

On the other side of the coin was the 3 months we spent trying to find a niche market. In this case, we followed a set process to test ideas and determine of there was a sufficient market to turn the idea into a business. We rushed the ideation stage and hurried to get to the point where we could test the idea through Google Adwords. Despite meeting weekly, we never did come up with anything and while we learned a lot, it felt more like drudgery than fun.

I think what killed our enthusiasm was quite frankly the focus on making money. Searching for a niche market isn’t about doing something you love; it’s more about solving a grinding problem, something that people are will to pay for. All of the niches we stumbled across seemed mundane; it was simply hard to get excited about it.

For me, if it’s just about making money, then there’s far easier and more dependable ways to do that. I already have a great job at a great company. I love web developing because you can create neat and innovative things. Some of those things might not be practical, but the who cares if your doing it for the enjoyment? I think the other TeamCampers on the team probably felt the same way.

A main theme of the Creativity, Innovation and Change course is getting to know yourself. Personal reflection tools like CENTER add a character development dimension to the course that is an important first step towards unlocking your creative potential CENTER is an acronym, that stands for Character, Entrepreneurship, owNership, Tenacity, Excellence, and Relationship. For me, my CENTER is:

  • Character: I love learning about new ways to do things and trying them out
  • Entrepreneurship: I’m unhappy with the status quo (especially when it’s not working) and I like to change things up (even if sometimes if sometimes it doesn’t work)
  • owNership: When I choose to do something, I learn everything I can about it to do it really well, be it cycling across Canada, learning to program in Rails or R, or oil painting.
  • Tenacity: I tend to get discouraged easily, so I need to put negativity and setbacks behind me and just keep going
  • Excellence: I plan to keep learning and creating and staying healthy until the day I die
  • Relationships: My family is my wife and my kids who mean everything to me; my community is the Ottawa startup community who are always enthusiastic, supportive and creative

Before you try something new, it’s important to understand yourself and what motivates you. It’s easy to get distracted from that and occasionally follow the wrong path.

Learning from these experiences I now know that for TeamCamp to be successful we need to:

  1. Brainstorm and constantly come up with many, many more ideas;
  2. Follow-through on the ones that have a high interest level for yourself and are aligned with your CENTER;
  3. Build it! Don’t worry about whether it’s going to make money. Rather, focus on making people happy through what you create (the money will come);
  4. Lead or join a team that has similar values to yourself.





“Test Driven” Development for non-programming related tasks

Lately I’ve been toying with the idea of applying the concept of Test-Driven Development to development methodologies for  non-programming related tasks.  Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions.

It strikes me that pre-written test cases could lead to a more successful new technology or process implementation.  For example, we are currently working on a project to introduce a new technology into a sophisticated telecommunications network.  Without getting into too much detail, this technology could dramatically lower the cost to deliver telecommunication services under a certain scenario.

What would the equivalent of “Test-driven” development look like in that scenario?  First, we need to define the “unit” that we are testing.  For this example, the unit of functionality we would like to test is that the technology can be deployed to 50% of our customer base.  This is a critical assumption and worthy of such a test: If the technology cannot be deployed to at least 50% of our customer base then we would either have to scale back our deployment or even discontinue the project.  On the other hand, if we find that we can deploy to greater than 50% of our customers we may have an opportunity to expand deployment and achieve even greater benefits than expected.

Let’s step through a typical test-driven development process to see how a this methodology would be applied in the example above:

Step 1 – Write tests

In test-driven development, each new feature begins with writing a test.

For our project, the equivalent of a “test” would be to develop a query in our databases that determines if 50% of our customer orders are being successfully deployed on the new technology.  The benefits of preparing this query ahead of time is that it forces us to think about how we would measure and track this information – something that is often neglected in implementation projects.

Step 2 – Run the test and see if it fails

In software develop the first test fails because the code to pass the test hasn’t been written yet.  Test-driven development forces a programmer to think about what a unit of code will produce before actually writing the code.  This leads to better code and a more productive programmer.

For our project, running our query ahead of time also fails because we have not yet deployed the technology.  However, to prove the concept we could run a query on a similar technology to test our assumptions.  Having proving our assumptions we are not only more confident about the potential success of the project but we also now have a query ready for the next step.

Step 3 – Write some code

In this step the software developer now writes the code that will make the test pass.

For our project, we would deploy this new  technology a test environment – first in the lab and then in the field under a controlled environment.  We now have all the pieces in place to run our test.

Step 4 – Run the tests and see them succeed

Running and passing a test in the software world proves that the code works.

For our project, we would process some test orders under different scenarios to demonstrate that indeed at least 50% of our customers could be deployed on the technology.  Having completed this step in a lab and out in the field we’re now ready to deploy the service to real customers.  We continue to run this test, i.e. running database queries to determine, if indeed, at least 50% of our customers are being deployed with the new technology.

Step 5 – Refactor code

In software development the programmer now cleans up the code as necessary, removing any unecessary duplication.  By re-running the test cases, the developer can be confident that refactoring is not damaging any existing functionality.

In our project this is where we have an opportunity to improve the deployment of the technology.  For example, perhaps we can achieve far greater that a 50% deployment by changing the way we use the technology.  If so, we could revisit the original business case and seek additional benefits.

This is a step that is often left out in non-programming related projects.  We deploy some sort of new process or technology and neglect to follow-up afterwards.  Maybe the process or technology isn’t achieving the benefit we expected?  Or maybe it’s even better than we expected and could be deployed on a larger scale then originally intended?  Either way, it’s important to “refactor” to ensure we are achieving the greatest benefit possible.


In software development, the programming starts over with another new test, and the cycle is repeated to push forward new functionality.

For our project this also makes sense: customer demands change; new technologies are introduced;  we would prepare a new “test” and follow through with introducing the new functionality following steps 1 through 5 above.

Applies to more than just technical tests

The same principles for test-driven development would also apply nicely to testing expected cost benefits.  For example, our business model assumes that the successful implementation of our project would result in a 75% reduction in customer access costs.  But how do we know that we are achieving those results without preparing the appropriate “test” ahead of time?  The answer is that you won’t unless you have developed a way to measure the expected financial benefit and have deployed the appropriate test to ensure the expected benefit is being achieved.


The application of “test-driven” development methodologies translates nicely to other non-programming related development tasks.  It introduces a new way of thinking: clearly understanding the expected benefits of a project and definging a way to measure those benefits before implemention.  Not only should it result in more successful and cost-effective project implementations, but it should also result in a more productive and content project team.

I hate printers

Printers never work right.  They’re always out of paper or ink.  The paper they use goobles up trees.  The empty cartridges go into landfills.  They’re expensive and need to be replaced far too often.

Yet, I’m often required to print out a document, sign-it, scan it and then email it to someone.  There’s something very wrong here.

The problem is even more aggravating when you’re a teleworker: you have to use your own printer, your own paper, your own ink – because for the small number of times you need to print something, it’s not worth expensing.

Let all teleworkers and employers of teleworkers unite! Bring an end to any task that requires a printer – please!

Dead Simple Ways to Prepare for a Job Fair

I just came back from a job fair at Carleton University in Ottawa.  It really struck me how unprepared the students and grads were.  Two simple things can improve your chances of getting hired:

  1. Research the companies that are going to be at the job fair – My company is the third largest telecommunications company in Canada, has over 6000 employees and annual revenues of almost $2B.  Only one of the 50 odd students/grads I spoke with knew who we were.  I had to spend the first five minutes explaining who our company is and what a telecommunications company does.  For god’s sake, if you really want to get hired do a little research beforehand!
  2. Bring some resumes to hand out – Sure, you can upload your resume and apply for a job online, but you’re much better off leaving something tangible before you leave.  Otherwise, how can you be sure that the employer will remember you or find your application later on?  Plus the employer can discuss your experience and qualifications with you and perhaps give you some career advice. It’s still a good idea to apply online but come with paper too.

These are two simple things you can do that will increase your chances of finding employment.  It will also optimize the short time you will have to talk careers with a perspective employer.

Ottawa Democamp10 & Announcing TeamCamp

Update: I’ve now created a wiki for TeamCamp

Ottawa Democamp10 was a blast! Just as promised, it was fun, friendly and informal.

Chris Taggart provided a demo of FixIt Ottawa – a local problem reporting tool. I spoke to Chris before his demo and I was really impressed by his hard work with the good folks at the City of Ottawa. Not only is Chris building a dynamic website but he also has to deal with government bureaucracy. I wish him the best in developing this site because I think it’ll be a great tool and I hope the City recognizes his contributions. It ‘s people like Chris who will bring our local governments, perhaps kicking and screaming, into the 21st century.

Aydin Mirzaee provided an amazing demo of and ScreeningRoom. As I watched his demos it became clear to me that the stunning interface the folks at developed not only represents the future of web applications but it sets the bar for desk-top applications as well. For example, in FluidSurveys you create web-based surveys by dragging and dropping questions, picking the method for responding, and adding flow controls, all from one screen.

I was also impressed by Gazaro, a platform that let’s you create your own personal sales flyer of the biggest and best deals of products that you are looking for in your area. I wish it was available before I bought that digital camera last week – I’m sure I would have paid less! These guys are taking intelligent search engines to the next level. It can even show you price trends over a time period so you can decide whether to wait before you make that purchase. I can’t wait for Canadian retailers to be supported. PS – check out the hilarious press release describing how Gazaro was selected as the winner of the “coveted and highly subjective Calacanis TC50 Disqualification award”.

Sixent is Ramius Corporation’s multi-profile social networking site. Sixent lets you control the way you share your online profile depending on whether you’re connecting with friends, family, business contacts, or the world. Imagine a Facebook that you could customize available content depending on who you’re sharing it with – that’s Sixent. The Enterprise version of Sixent could be a clever way to get social networking accepted by businesses that have not quite embraced the whole social networking thing.

Thanks to some Internet connectivity issues, Andrew Ross from osbootcamp sneaked in a demo of Ingress Cafe. This opensource product is a java application development tool that accelerates and simplifies development with Java. Ingress Cafe was selected as the Best Application Development Tool at LinuxWorld Conference & Expo this week. Impressive!

DemoCamp Ottawa reminded me why I love this city. Not only is it one of the most beautiful places in the world but we also have the most talented and creative thinkers around.

I took the plunge and provided a demo of one of my Rails applications, GiftMyList. I was truly taken aback by the warm and supportive response I received from the audience during and after my demo. It gave me the encouragement I needed to complete this particular project, and to get cracking on others, which brings me to the second half of this post…

Announcing TeamCamp

Team Camp is a series of events aimed at forming like-minded individuals into teams for the purpose of turning ideas for software or web applications into successful businesses.

If you are…

  • Someone with an idea that you would like to turn into a web or software business,
  • Working full time but, wanting to take the start-up plunge part-time before the BIG leap,
  • A student looking for start-up experience,
  • You have experience with start-ups and just want to lend a hand

… then come to the first TeamCamp meeting:

Date: Thursday, 9th October, 2008
Time: 6pm to 8pm
Where: @ TheCodeFactory (246 Queen Street)

How do you get involved?

Step 1. Contact Chris: chrisjchmitt[@]gmail[dot]com or Ian Graham: info[at]thecodefactory[dot]ca.
Step 2. Attend the kick off meeting.
Step 3. Bring your ideas!

Why are we doing this? In a recent Sitepoint post, Daniel Burka’s advice to young designers put it perfectly:

I’d strongly encourage them to find people with like interests and start working together on stuff. Build fictitious projects, and try stuff.

If this sounds like you then come on down to the first TeamCamp! (except we’re going to work on real projects)

A special thanks to Ian Graham at The Code Factory for his help and encouragement, and for providing us with a fantastic venue for hosting these events.

– Chris

The challenges of implementing collaboration tools

Much has been said for using the Web for team collaboration. But actually putting this technology into practice is a lot harder than it sounds. For example, I’ve had a lot of trouble convincing my staff to use Basecamp. I manage a geographically dispersed department within a large corporation that has number of cost reduction projects underway. Basecamp seemed like the perfect fit.

My motivation behind using Basecamp (which by-the-way is an amazing product) was to use the Messages forum to reduce the amount of email and provide a record of discussions, to introduce some simple project management, to provide a central place to store our files and to use the Writeboard to collaborate on important documents.

After having implemented Basecamp for a month I found that most of the staff were not logging in or participating in the discussions. While some of my team saw the potential for the application others complained that Basecamp added to their workload and that its easier to collaborate using email.

I used the Basecamp forums to find out if others had experienced the adoption challenge and if they had any advice on how to overcome it. I received a lot of advice. Later, I held an evaluation session with my staff and the outcome led me to a few conclusions:

  1. Basecamp (and other collaboration tools) work better on projects rather than daily activities.
  2. The sooner you get all of your projects into the collaboration tool the better.
  3. Everyone with a significant role on a project needs to use the tool (this was a bit of a challenge in my organization since not everyone wants to use the application and they don’t all report to me)
  4. Management derives the most immediate benefit from the collaboration tool because all the projects are nicely tracked in one place.
  5. Staff with minimal project activity view collaboration software as ‘just another tool they have to use’.
  6. Many staff are worried about the security.

To address some of these challenges I’m now switching to our corporate SharePoint (WSS) site. WSS solves a few of the above mentioned challenges:

  • WSS is obviously secure because the server resides within the intranet;
  • WSS is linked to the company directory (plus WSS is the company standard) makes it easier to include anyone on a project, regardless of whether they report to me;
  • Document storing, sharing and workflow work quite well.

That being said, it’s still hard as heck to try to get others on board for any WSS capability other than shared documents. Employees are hooked on email, and that’s that. And while SharePoint is highly configurable, it’s not as easy to use as Basecamp. Add to these challenges that the majority of the employees within an tradition corporation are not typically “web savvy”.

I believe the key is to integrate the use of collaboration tools into your processes, provide the prerequisite training and then enforce the use of the application. Once that’s done then I’ll circle back, find out who’s using it (and why), who’s not (and why), and just keep at it.

If you think deploying a collaboration application in the Enterprise is simple – think again!

Moving hosts

I’ve temporarily moved this blog to WordPress. I will soon be setting up a rails-based blog on my new webhost. Stay tuned.

Update: I’ve decided it’s easier just keep using  I’m too busy writing real Rails web apps to be messing about with a Rails-based blog.