OSDev.org

I find I am developing software alternating between two phases:

* Implement new feature. (Perhaps in a rather quick and messy way - values are hard-coded, code may need refactoring, etc.).
* Spend a lot of time refining the whole codebase (integrating the new feature) to my liking.

I think I can eventually achieve what I consider good code, but it takes a lot of time and effort.

I'm wondering, am I just not experienced enough to write quality code right away? I suspect no one writes a masterpiece in one go, and I'm not about to beat myself over not being able to.

Do some of you work in a similar way?

My style is quite similar: work for some time on one or more features, then when I feel things are getting too messy spend some time cleaning up (especially warnings). I do it that way to avoid wasting time on code that may end up getting deleted anyway.

Over time I find at least some code "settles" and changes little. Having a good architecture is more important than having "perfect" code, I think.

It is also why I find it important to break up work in small chunks: sometimes I try to do too much at once and it is hard to clean up if you're still making a lot of changes. In such cases I tend to do the minimum to get the project in a usable state again, then just merge even if it is unfinished. I can clean up afterwards.

If I do have a (very) good idea of what I need to implement I might go straight for clean code though.

The mantra I live by is:

"Make it work, correct, optimized, in that order"

So first I just need it to do the thing I want it to, which is also sometimes the "is this possible" phase if Im exploring something new. Then I try to clean it up but less for organization and more for correctness -- edge cases, remove hard coded stuff (like you said) etc. Then, as is reasonable or needed, I'll optimize it a bit. A lot of the time the last step is more of a sanity check Im not doing something terribly wrong and I'll only enter a full optimization phase if something is super critical or if I have the time to do so (which is not often lol).

Good code is illusive and the engineer in me says good code is the code that does the thing you need it to haha. I think as time goes on we all get a bit better at raising the bar of minimum code quality but beyond that the good code is just so dependent on what you're doing that its kind of hard to really define anything. I'd say we are all pretty good at seeing bad code and beyond the obvious examples like Fast Inverse Square from Quake 3, and other similar instances, good code is more of an idea than a reality.

This isn't to say pursuing good code isn't fun -- I like to really sit down and think about having that perfect level of abstraction (not too much not too little) and its generally enjoyable/satisfying to write something particularly nice! Just dont be too hard on yourself as you develop <3

I also work in the "tick/tock" method of adding a feature and then cleaning things up later. My reasoning is that I tinker with OS development for two reasons.

The first is to learn more about low level development and hardware, which I usually do in a frenzy of adding a feature such as a new driver or a new kernel service. Usually I can get the rough outline of a new feature done in a weekend, and I'm usually in a rush to get it done by the weekend as I know I probably won't get a block of time that big again for a few months.

The second reason is to learn and practise my C development skills, and to practise good software engineering skills. Software engineering is also my day job, but from time to time I have to cut corners I wouldn't want to in the cause of budgets or time restraints - having no budget or time restraints in my personal projects is the antidote to this. And this cleaning up and making things adhere to best practises can be done 15 minutes at a time on rainy evenings whilst watching TV - no huge amount of deep work is required.

I work in a similar way, but I’m increasingly using unit tests to ensure that each iteration doesn’t break anything. One approach to programming is to write the unit tests first then keep modifying the code until it passes all the tests.

iansjack wrote: ↑Sat Jan 10, 2026 12:39 am I work in a similar way, but I’m increasingly using unit tests to ensure that each iteration doesn’t break anything. One approach to programming is to write the unit tests first then keep modifying the code until it passes all the tests.

I've been a bit lazy and haven't learned unit testing in C/C++ (though I'm very familiar with it in Java and C#). Are there any tricks to unit testing a kernel?

I use unit testing for modules rather than the kernel as a whole. For example, I wrote my filesystem as a normal standalone user program with dummy calls to read and write sectors from a disk image file. Then when satisfied that it passes all the tests it’s easy to incorporate it into the kernel. I’m doing the same thing with a network stack at present.

Working this way also allows the use of valgrind to check for memory allocation problems.