Some advice I received regarding embedding features into a device

One thing we struggle with, even with the access to the phone programs that we have, is the different time scales for phone, PC software, and Web development.

The development and response times are vastly different:

– A phone takes 1.5-2 years to make. Specifications are frozen way before the device ships. The learnings then take another 1.5-2 years to make it into the product line.

– PC software is usually frozen about 6 months before shipping. But, you can be pretty responsive at a 6 month to 3 months level (or at least it seems that way).

– Our Web software is usually ready when we code it in our 2-4 week sprints. And we are pretty responsive to changes.

Nothing new there. But, imagine having to give a specification to a device program for a Web service you haven’t even figured out, much less started building, much less know if folks will accept. I get in trouble all the time for ignoring the device and how it can help me with stuff that I am building _now_.

A colleague then made a great comment: The device is not an innovation platform (embedding the software, that is). We should focus on the faster tools of Java and Web services to explore what works and what doesn’t. Only when we know what is good, do we then work on embedding the service into the device.

When embedding something into the device, it needs to be good and smooth. But, if you try to shove something unproven into the device, trying to get it to match the innovations and explorations happening in the faster time scales, you risk a lot of head ache.

Being at an early stage of exploration, myself, I now know what to say when I get hollered at for not thinking of what to embed into the device.