First, I want to say that I'm not going to be a reactionary Voom customer and threaten to
cancel, or file a complaint with the FCC, or register voomsucks.com and start an activist
web site. I think the service has potential and it's evident that the people behind it have
vision and good intentions.
I do believe however, that there is a fundamental problem that, unless corrected, will
cause a level of customer dissatisfaction that will prevent Voom from reaching a
critical mass and enjoy long term growth and success.
The problem? The Voom receiver's software.
I'm just an observant customer. I don't have inside knowledge of Voom's source code,
or what the constraints are in the hardware and firmware supplied by Motorola.
I have developed, or been involved in the development of enough software based
consumer products that after a few months of using some device, I can get a feel of
what lies beneath.
It's not really question of features or the user interface path, although "the problem"
is reflected in those things. Here's my guess, and it is a guess, of what's wrong.
Voomware appears to be one of those projects that incorporates "modern" software
development methodologies. Things are planned out "on paper" to the smallest detail.
Tools like Rational Rose, UML and use case planning and testing. An architecture is
developed that's message based and object oriented. Then, after it's all planned out,
coding starts and the paper model is turned into reality. Because everything is modular,
you can have separate teams that can work on those modules, and then, when it's all
plugged in together, it's hoped that the result is a perfect, bug free, feature rich product.
But what often happens is software that's slow to boot, sluggish in operation, and is
plagued with strange bugs that are as unpredictable as they are perplexing for both
customers and the developers charged with fixing the bugs.
We see reports of odd behavior in the Voom forum, things like mismapped
channels, the preview window sticking in the upper right corner, the boxes hanging
and requiring reboot, inexplicable wonky behavior... there's "the problem". We know
that there are bright people building the product, how could they release something
with such obvious problems?
When you base a product on such an architecture, when a feature is requested that
wasn't envisioned during the design phase (like OTA channel scanning), the ripple
effect to graft in new functions can be maddening. Suddenly, all kinds of unforeseen
side effects pop up and delivery of the software is delayed again and again.
This clever object based approach also takes a lot of cpu cycles to run. Every time a
single bit changes in the state of the machine, thousands of bytes need to be moved
around to pass messages between software modules. It all seems good on paper during
the pre-implementation phase but in the real world, it runs like a slug and the user
sees peculiar side effects and system lock ups. You can see this effect when rapidly
changing voom channels. The massage passing starts to swamp the relatively meager
set-top cpu and it takes several seconds for the box to catch up, or occasionally, the
messages get out of sync and the box locks up.
Although it's possible to ....eventually... fix these problems, it's not likely until voom
changes it's design and development methods. In the old days, when we were not
so "smart", when programmers could get down to the hardware and not add this level
of abstraction to give management the illusion of participation in the coding process,
stuff would "just work". (Apple seems to kind of get this concept).
Voom needs to start looking at the project from the user on down, not from the computer
on up. Just because the code fits the model designed "on paper", and the use cases
all pass testing, and the flowcharts map everything out to the smallest detail, doesn't
insure that you can ship a product that actually -works-.
(I wish Apple was building Voom boxes...)
Bill Romanowski
TQworld.com
cancel, or file a complaint with the FCC, or register voomsucks.com and start an activist
web site. I think the service has potential and it's evident that the people behind it have
vision and good intentions.
I do believe however, that there is a fundamental problem that, unless corrected, will
cause a level of customer dissatisfaction that will prevent Voom from reaching a
critical mass and enjoy long term growth and success.
The problem? The Voom receiver's software.
I'm just an observant customer. I don't have inside knowledge of Voom's source code,
or what the constraints are in the hardware and firmware supplied by Motorola.
I have developed, or been involved in the development of enough software based
consumer products that after a few months of using some device, I can get a feel of
what lies beneath.
It's not really question of features or the user interface path, although "the problem"
is reflected in those things. Here's my guess, and it is a guess, of what's wrong.
Voomware appears to be one of those projects that incorporates "modern" software
development methodologies. Things are planned out "on paper" to the smallest detail.
Tools like Rational Rose, UML and use case planning and testing. An architecture is
developed that's message based and object oriented. Then, after it's all planned out,
coding starts and the paper model is turned into reality. Because everything is modular,
you can have separate teams that can work on those modules, and then, when it's all
plugged in together, it's hoped that the result is a perfect, bug free, feature rich product.
But what often happens is software that's slow to boot, sluggish in operation, and is
plagued with strange bugs that are as unpredictable as they are perplexing for both
customers and the developers charged with fixing the bugs.
We see reports of odd behavior in the Voom forum, things like mismapped
channels, the preview window sticking in the upper right corner, the boxes hanging
and requiring reboot, inexplicable wonky behavior... there's "the problem". We know
that there are bright people building the product, how could they release something
with such obvious problems?
When you base a product on such an architecture, when a feature is requested that
wasn't envisioned during the design phase (like OTA channel scanning), the ripple
effect to graft in new functions can be maddening. Suddenly, all kinds of unforeseen
side effects pop up and delivery of the software is delayed again and again.
This clever object based approach also takes a lot of cpu cycles to run. Every time a
single bit changes in the state of the machine, thousands of bytes need to be moved
around to pass messages between software modules. It all seems good on paper during
the pre-implementation phase but in the real world, it runs like a slug and the user
sees peculiar side effects and system lock ups. You can see this effect when rapidly
changing voom channels. The massage passing starts to swamp the relatively meager
set-top cpu and it takes several seconds for the box to catch up, or occasionally, the
messages get out of sync and the box locks up.
Although it's possible to ....eventually... fix these problems, it's not likely until voom
changes it's design and development methods. In the old days, when we were not
so "smart", when programmers could get down to the hardware and not add this level
of abstraction to give management the illusion of participation in the coding process,
stuff would "just work". (Apple seems to kind of get this concept).
Voom needs to start looking at the project from the user on down, not from the computer
on up. Just because the code fits the model designed "on paper", and the use cases
all pass testing, and the flowcharts map everything out to the smallest detail, doesn't
insure that you can ship a product that actually -works-.
(I wish Apple was building Voom boxes...)
Bill Romanowski
TQworld.com
