Lack of Specifications (was my work...)

Andy Green andy at
Fri Jun 6 08:35:00 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

| - I think Raster made a good point when suggesting to use a
|   microcontroller that does not require a development environment
|   too different from the one we're already using.

OK another s3c2442 it is then.  Maybe one more to make sure.

I mused about where the actual problem here comes from when I woke up
thismorning, like other running sores (eg, packaging system behaviours)
I think the actual problem here is lack of a detailed spec, a solid
goal.  We're flying by the seat of our pants in all areas based on where
we are, not where we are going.

I do not mean seeing "has an MPU" in the spec.  If the spec just took
care enough to say, "charging LED consistently shows charging state at
all times, even when device is 'off'", we narrowed it down to wiring
that LED to PMU GPIO or having an MPU.  A few more assertions in the
spec in other areas best dealt with by an MPU, and then the MPU is
accepted with no argument.  (And on the other hand, if truly nothing in
the spec can benefit from it, and we can't get the maintainability
argument to fly: fine, no MPU was needed.)

Instead what we got is us making these policies on the fly at
implementation time, leading to reactionary "Hell, no" experts trying to
guide the actual design of the device behaviours in realtime with about
as much right as I have to do it.  The endless situation of not having a
detailed spec to work against sets us all up for !success.

Folks on the community list compare GTA02 to iPhone, I really doubt the
guys at Apple are suffering the same muddle when it comes to device
behaviours; bearded guys in pastel cardigans hand down tablets of stone
about how their device should present itself from day one, because they
have a detailed vision about it they can articulate.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list