How much design do you do ?

[wichtounet]

Hi,

I would be interested in knowing how much design do you put in your operating system development ?

From what I can see in the forums, there are people who do a really great deal of design before getting their hands dirty.

Personally, I don't do a lot of design, at least not in the grand scheme of things. Once I want to a new feature in the OS, I think about how to integrate it inside the existing architecture and then I get to code. Once I feel it's necessary, I refactor the code and the architecture to make it better or more suited for later features. I don't like doing a lot of design for my personal projects, but I love finding solutions for each problem independently.

What about you ?

Baptiste

[Brendan]

Hi,

What about you ?

I do a huge amount of research and design, resulting in draft formal specifications for my OS (that exist before something is implemented). Then (while implementing things) those drafts are adjusted if necessary.

Eventually (at the OS's first release, which won't happen until I'm happy with the complete set of formal specifications) all the specifications will be promoted from "draft" to "version 1.0".

Note that part of the idea here is that the specifications are the OS (in the same way that SYS V and POSIX are "Unix"), and the code I write is just a implementation of the OS (in the same way that FreeBSD is just an implementation of Unix) where anyone could write a different implementation for some or all of the OS that complies with the same specifications (in the same way that there's many different implementations of Unix).


Cheers,

Brendan

[matt11235]

I'm the worst at planning.
If it's something which I need to plan (coursework) I usually end up writing the plan afterwards

[Mikumiku747]

It's fun to just jump in and start implementing something, but it's important to realise that while you might not think it now, eventually, something you didn't plan will come back to bite you in the @$$, one way or another (Although if you never make it to eventually, then you'll be happily immune to this problem). It's also good to remember, planning doesn't guarantee you'll write it properly the first time, however, it makes it a lot easier to look back on what you did before and see what you did wrong. Just be careful that you don't get too caught up in planning the perfect system and then never get around to implementing it. No planning at all is a nightmare to look back on, and too much planning means you'll never get to the point of looking back on your work, so try to get a healthy balance of both.

But that's just speaking from my own experiences, which are quite limited, and so I would take it with a hefty pinch of salt.

[rdos]

I'm like the OP. I design in my head and mix design with implementation. I don't like to design things first and then implement them in a sequential order.

[Kazinsal]

I have a process that's something like design -> prototype -> refine -> implement -> formalize, and during these phases I draft, edit, and formalize relevant sections of the admin and user guides for the OS. This way, when the OS hits a proper release, there will be an accompanying book available in both eBook and "dead tree" format -- the latter probably both soft and hard cover.

If the OS ever takes off (which I hope it does to a degree) and people buy the books I will likely end up offering to owners of hard copies updated versions of hard copies (eg. at new major releases) at cost instead of at full "retail" price.

[Sik]

Personally, I don't do a lot of design, at least not in the grand scheme of things. Once I want to a new feature in the OS, I think about how to integrate it inside the existing architecture and then I get to code. Once I feel it's necessary, I refactor the code and the architecture to make it better or more suited for later features. I don't like doing a lot of design for my personal projects, but I love finding solutions for each problem independently.

There's a catch there: that existing architecture is already influencing your design (effectively becoming a shortcut). You will probably end up with something that's similar to what's already there, and probably even takes advantage of the already existing features.

A lot of the planning you're seeing comes from before the architecture even exists, which means the design pretty much has to be made from scratch. No shortcuts available to take here.

[Schol-R-LEA]

Something on the order of twenty years' worth. And I'm still at it.

[wichtounet]

Thanks for your answer, that's very interesting. It seems that most of us have different techniques

I'm impressed on how much design some of you do. Congratulations on that! I something wish I could motivate me to do more, but I'm really more into code.

For a hobby project like mine, I would not consider full formal documentation, but it seems that some of you do it more seriously than I do though. I have some documentation, but mostly written a priori and a lot of it is still on paper.

There's a catch there: that existing architecture is already influencing your design (effectively becoming a shortcut). You will probably end up with something that's similar to what's already there, and probably even takes advantage of the already existing features.

A lot of the planning you're seeing comes from before the architecture even exists, which means the design pretty much has to be made from scratch. No shortcuts available to take here.

You're right, the existing features and design do influence the new features. Nevertheless, I try to polish the existing as much as possible with refactoring when I can. Since I enjoy some refactoring and a good design, this is not something I mind. With this technique, I've something working quite early, even if not perfect.

It's fun to just jump in and start implementing something, but it's important to realise that while you might not think it now, eventually, something you didn't plan will come back to bite you in the @$$, one way or another (Although if you never make it to eventually, then you'll be happily immune to this problem). It's also good to remember, planning doesn't guarantee you'll write it properly the first time, however, it makes it a lot easier to look back on what you did before and see what you did wrong. Just be careful that you don't get too caught up in planning the perfect system and then never get around to implementing it. No planning at all is a nightmare to look back on, and too much planning means you'll never get to the point of looking back on your work, so try to get a healthy balance of both.

That's very well said and so true indeed.

In the end, as long as the objective is fullfilled, it all comes to down to personal preference I guess (in the context of hobby project of course).

[glauxosdever]

Hi,


Over the total course of my OS development journey, there have been various degrees of how much design I do.

Roughly two years ago, when I was writing the OS in assembly, I wasn't doing any serious design. I was writing things as they came, without caring much whether it's well designed or not. Eventually, it became a total mess.

Roughly a year ago, I decided to rewrite the OS in C and to follow POSIX. As months passed, I started seeing way too many unsafe functions and suboptimal interfaces.

This period, I try to design something new from the start, without caring much about C and/or POSIX. Right now, I'm designing a new programming language. A simple and consistent API will come next. Then, after making sure everything is good, I will start implementing the whole design.


It should be noted that you usually decide the degree of how much design you do, depending on whether you want to simply write an OS that will fulfill your confidence as a programmer, whether you want to write an OS that will help you in your education and/or your career, or whether you want to write an OS that is destined for other people to use. For the last case, you also have to consider what kind of people will use your OS, and you have to design it accordingly.


Regards,
glauxosdever

[DavidCooper]

The two extremes are either to design everything first and not have a working operating system at all until a decade or two later, or else to build a pile of crap straight away and then spend a decade or two rewriting parts of it over and over again and still not having anything close to a good OS by the end of that time. Fortunately, there is a middle road which gives you the best of both worlds, and that's to design everything in just enough detail to be sure that every part of the OS that you build early on can be replaced with more capable versions over time without ever breaking too much else in the OS in the process, thereby allowing you to evolve it efficiently down a planned path towards perfection. That means avoiding making big mistakes. Many people decide to write a real mode OS as their first step, for example, but at some point they're forced to rewrite the whole damn thing in one go in order to get any further, so that's the kind of trap to avoid (unless the aim is to stop there and just be satisfied with having built a simple OS for the fun of it).

Keep looking ahead at where you want your OS to end up and make sure you aren't accidentally building any barriers between yourself and that goal. If you do this, you can write a simple OS early on and get good use out of it long before it's anywhere near perfect. Read up on what the top designers are doing (or say they're planning to do) and try to understand why; then see if you can get something simpler up and running straight away which you can evolve in the right direction over time. There's nothing wrong with starting with a primitive OS and not designing everything in extreme detail up front, just so long as you avoid all the traps that might keep it stuck permanently in that primitive state. For many people the main aim is to get into the specific parts of the OS that are of the most interest to them (where they want to try out or demonstrate new ideas), and there's very good reason for them not to waste time trying to build a perfect OS first because they need something that functions right now rather than twenty years down the track. That is in no way a criticism of the fully-planned-up-front approach though for people who require the full package in order to demonstrate the power of their vision. How you work will depend on your goals.

[Ycep]

My amount of design couldn't be static! It depends!