One of the courses I teach, which I’m quite proud of, is the
capstone course for the CS and IT majors.
In the two semester course, we design, build, and release something to the
world. The projects are based on interests
in the various groups, usually 2-4 people per group. We’ve built robots, network sniffing tools, video
games (some better than others ;)), and a variety of web portal kinds of
tools. This cycle, one student team built
an existential video game called Unbearable which was impossible to win and
whose arcade-style high score tracker published random numbers. It was a silly game on the surface but had
lots of ironic and fun easter egg kinds of behavior.
The other teams collaborated to build what was functionally
a tele-presence device. The intent of
the device when they started was to be able to “call home” to see your dogs and
make sure they were ok. They had
promised “bark recognition” software that would send you a text if the dog was
barking too much and a Pan-Tilt-Zoom functionality for the camera so you could
watch the dog. Early designs had a ball
thrower so you could play with the dog remotely but that was simply too complex
for the time we had. There had been some
discussion about blowing bubbles for the dog to chase instead or perhaps giving
the dog “some kibble” to get it to come to the device. The “kibble launcher” became the in-joke for
the two semesters but was kind of moved to “nice to have” instead of a
requirement.
Last night, the team demo’d their product with the intent of
showing the customer that the product should be funded to actually be built. One of the team members brought their dog in
to show the reaction to the device.
Generally, the dog was less than impressed J We joked that they should have included the “kibble
launcher” after all to get the dog’s attention.
The student responsible for the case that the telepresence device lived
in reached under the desk and pulled out a small box-like object which he
hooked onto the side of the device. You
could see there was a place for wires and a motor though they had not actually
been installed. He then reached into his
backpack and pulled out a baggie of dry dog food which he loaded into the new
add-on. It was manually activated but
the dog was excited to get some “kibble” so at least hung around the device
during the demo. Network issues in the
classroom prevented the demo from working well but we had seen the process work
in the past.
The reason I bring this all up is that the “kibble launcher”
started as a joke with the team while we were brainstorming the functionality
of the product. In brainstorming, you
write down all the ideas that come up, no matter how odd they may seem. Using Affinity Diagrams and other tools, we
pared down the ideas to a manageable number of requirements to build. The launcher was decided to be a “if we have
time” kind of feature and it was shelved.
But, we made so much fun of the idea that the cabinet builder kept
thinking about how to actually do it. He
mocked up a prototype which he proudly displayed last night. It helped their product and would have
differentiated it on the market if we had really built it.
My point is that we often come up with crazy ideas in
brainstorming sessions and we filter them out right away because they’re
silly/stupid/too expensive. But
sometimes, those ideas live on and we find a way to incorporate them into the
product. And we should. Those “crazy ideas” are how we sometimes get
new, cool products.
Posts
