OSDev.org

Alright, I'm thinking about rewriting my OS.

I started about 2 weeks ago, and to be honest, I didn't really have a crystal clear plan on how'd I go, and the steps. But now that I have a extremely basic operating system with a CLI and such, with basic program loading, exception handling, dumping etc, I have a much better idea on how things should be.

I think not knowing how things will be will cause a bad foundation, and building on top of a bad foundation is asking to fail, IMO.

Over the time I've been devving, I've gained knowledge and stuff that I didn't have before, and I realize now, that my code is getting somewhat redundant and harder to maintain the more I add stuff.

I'm thinking about restarting, because honestly, 2 weeks is not much, and now that I have a clearer vision, I think I can implement things in a more orderly and efficient way.

Any ideas on restarting, or any people have restarted a project? Opinions please.

Hi,

supershirobon wrote:Any ideas on restarting, or any people have restarted a project? Opinions please.

If you restart, what will prevent you from learning more while writing the new version and then wanting to restart again in another 2 weeks?

This is a natural and unavoidable cycle - the knowledge and experience you gain while writing "version n" can be used to write a "version n+1" that has better code and/or has increased scope. There's only 4 ways to break the cycle:

• be happy (learn to accept code that is worse than you are capable of now)
• be stupid (don't learn anything or gain any experience, so that you're not capable of doing better next time)
• be perfect (almost impossible)
• be prepared (risk minimisation)

Being prepared means doing things like continuing with "version n" (even after you've decided to restart) to learn as much as you can before you start "version n+1" in the hope of avoiding or postponing a "version n+2"; and splitting things into pieces/modules and spending a lot of time researching the best design for the interfaces between those pieces (so that you can rewrite individual pieces instead of rewriting the entire thing); and being ambitious ("scope shrink" is easier to handle than "scope creep").

For example, if your existing code doesn't support multi-CPU, then you might want to slap some crappy multi-CPU support into the existing code (it doesn't need to be good), just to gain knowledge and experience that can be used in the next version of the OS. For another example, you might want to design an interface (function declarations, API, whatever) for a complex/high performance/scalable physical memory manager and then just implement a "quick and dirty" simple physical memory manager that uses this interface, so that later on you can replace the physical memory manager with something better (without touching any code that relies on the physical memory manager's interface).


Cheers,

Brendan

Be happy sounds like a good way, although I prefer the (unlisted) option of "accept non-optimal code, perfectionism won't get you anywhere". If something is less than optimal, you don't throw it all out, but implement a better algorithm incrementally. In the end you will reach similar functionality and code quality, but in far shorter time.

In order for incremental changes to work the code must be written in a good way (isolation and clean interfaces), and if you have a lot of badly written code you will need to start over again instead. Learning to develop with incremental changes requires better code quality, which makes for less bugs (a positive feedback loop).

For a OS project with only 2 weeks of work I'd say just go for a rewrite. It really doesn't matter in that case.

Brendan wrote:There's only 4 ways to break the cycle:

• be happy (learn to accept code that is worse than you are capable of now)
• be stupid (don't learn anything or gain any experience, so that you're not capable of doing better next time)
• be perfect (almost impossible)
• be prepared (risk minimisation)

Well said, except I'd go with "be good enough" as the third option.

I don't mean to sound rude, but is there really so much to re-write after just two weeks of development? I think, that a code base started two weeks ago would still be malleable. Though, it may be just me - I don't consider myself a very fast programmer.

I can very well imagine several situations that you want to throw away code that you've just completed. It doesn't even need two weeks:

Michael Abrash wrote:In fact, I’ll take this opportunity to coin Carmack’s Law, as follows: Fight code entropy. If you have a new fundamental assumption, throw away your old code and rewrite it from scratch. Incremental patching and modifying seems easier at first, and is the normal course of things in software development, but ends up being much harder and producing bulkier, markedly inferior code in the long run

I've had two full rewrites since I started, and typically every component I add gets written twice: once to see how it works, and once to make it maintainable.

Sometimes you don't really know what problem it is you're really solving until you get your hands dirty with it.