Niklas Ekström wrote:
Since I'm not working on OpenBIOS I guess I shouldn't comment on how it should be done. But as a general though about programming (and possible all intellectual work at all), my opinion is that you should first make a strategy and write a design, and first after that start to do the actual work (code). When solving a physics problem you don't start by doing experiments and first after that find out what the experiments was good for, if at all (atleast that's not the way you _should_ do it! ;). From the above you can probably guess what I think about the "hack-and-go" approach I've seen mentioned here at times.
"hack-and-go" is known more formally as a more iterative approach to design. In my experience up-front designs are helpful as roadmaps, but are _very rarely_ accurate once you reach the end of the road.
As many open source projects have shown, all you need is a discriminating maintainer in order to succeed, NOT a good design. A poor design will show up quickly, and patches from developers will follow shortly thereafter. That is what the history of open source projects have shown so far -- the design gets iteratively better and better as time passes.
Further, hack-and-go means that results are in the hands of users more quickly. And we developers should never forget our target audience, and their desired results...
Jeff "hack-and-go" Garzik