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 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community