Slashdotted

[Steve Mosher]

Hi buddy!

Werner Almesberger wrote:
> Steve Mosher wrote:
>> hardware world. I'll use another metaphor. Building hardware  requires
>> a "waterfall" design process, at least in my experience. In the software 
>> world, outside of DOD and NASA, we'd be hard pressed to find projects
>> that followed a strict waterfall model.
> 
> Hmm, I think one risk of having a "heavy" development process is
> that everyone tries to cram all their pet ideas into the project
> like there's no tomorrow. And yes, I have to plead guilty there
> as well :-(
  Yes. This is all controlled by the requirements in a proper process
since the requirements specify a target BOM and launch date. The 
phenomena you refer to is called feature creep.
> 
> I think a useful compromise would be a rigid process from design
> to prototype or product, but the ability to start such processes
> in rapid succession.
yes, ideally with multiple dev teams and a standardized archetecture
I've seen this work.
> 
> A lot of problems in the GTA01/GTA02 design were only found after
> they hit end-users. Instead of bickering for half a year about
> buzz fixes, wouldn't it have been easier in the end if we had
> just been able to start a new design, with the necessary changes,
> but only them ?
Of course. I don't want to rehash particular decisions, but most
product shortcomings ( in all products) can be traced back to poor
requirements or badly expressed requirements.
> 
> This isn't of course something you just decide and it's done.
> You have to design the company/organization around such an idea.
> E.g., don't produce at a factory that could spit out a million of
> units a week but that takes three months to get rolling.
> 
>> minimum, plus a redesign. Take the appendix out--perform a glamoectomy?
>> ask Werner about the design implications of that on WIFI.
> 
> From (painful) memory: Half a month of getting a straight answer
> from the vendor whether the chip can do it, about two weeks of
> figuring out how to best rearrange that whole software stack such
> that the problem becomes solveable, a few days of implementation,
> well above a month to find out why that perfect plan didn't work,
> followed by a few more days of working around the silicon bugs
> eventually discovered. Ah yes, and when it was done, it didn't get
> used :-(
Sorry to bring up painful memories. To use another metaphor, lots of 
people thing of parts on a board as pieces of code you can just comment
out and recompile.
> 
> When assessing the complexity of a problem, we tend to see only
> those few days of actual development, not those months of
> unexpected consequences.
yup..
> 
>> The OM designs all used "modules" for GSM and modules for things like
>> WIFI and BT as opposed to "down" designs or chips on PCBs. The diffculty
>> is not in finding components or modules
> 
> Famous last words ;-) I'd humbly submit that it can be incredibly
> painful to find certain components if you're not a really big
> player. And sometimes, one has to use components that aren't even
> designed for phones, which creates its own set of problems.
  true.
> 
>>   The voting approach will be discussed. Basically I dont believe in 
>> letting idiots vote.
> 
> In Linux, we have the concept of "benevolent dictators" ;-)
   I think we are back to that discussion we had in the cab about 
consensus and debate. I've softened my position somewhat.

> 
> Very nice and insightful post. Thanks !
> 
> - Werner