
www.Usenet.com
| <-- __Chronological__ --> | <-- __Thread__ --> |
Greg Kemnitz wrote: > ... snip solid advice ... > > 2. Good design with API's graven in stone, including reasonably > precise documentation. In a startup, good coding fences make > for good neighbors, particularly when programmers have to work > at warp speed - and, by necessity, are often domain experts in > different fields - so peer strategies like code reviews are of > limited utility. > > API's should be designed before much code (if any), is written. > API's should be stub implemented and integration done early as > well, so that gotchas in API design can be isolated and rooted > out before they break the world. (Stub-implementation of API's > has the additional useful property of permitting "real" demos.) Much depends on what you mean by API. Of course you have to design the interface between modules before implementation (and as far as I am concerned any OS is just another module), and once done changes in such interfaces are grave decisions. But the important thing IMO is to do the design top-down. That will do the initial partitioning, and the interfaces will develop naturally from the demands. -- Chuck F ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
| <-- __Chronological__ --> | <-- __Thread__ --> |