It's recently been a year since I started working on my pet OS project, and I often end up looking backwards at what I have done, wondering what made things difficult in the beginning. One of my conclusions is that while there's a lot of documentation on OS development from a technical point of view, more should be written about the project management aspect of it. Namely, how to go from a blurry "I want to code an OS" vision to either a precise vision of what you want to achieve, or the decision to stop following this path before you hit a wall. This article series aims at putting those interested in hobby OS development on the right track, while keeping this aspect of things in mind.

I don't think anybody here was referring to the prototype. Never the less, if your prototype is functional enough that it can be used for performance analysis, then it seems to me that you've already put in a significant investment, no?

Depends on the case, but yes, the first prototype *can* be a major investment. Point is, if you invest in anything else, your investment is most likely lost. What the actual requirements of a project are, and what you think they are, usually differ so much that you'd be starting into a totally wrong direction. A prototype then often shows you the right direction.

Remember, a correct and complete requirements specification only happens in fairy tales, and when you ask your users on a purely theoretical basis, i.e. without a prototype, they won't give you realiable information.

In any case, if you believe in building a separate prototype and using that for performance analysis, then you really ought to agree with me that planning for an efficient design up front is important since that's essentially what a prototype is.

No. The prototype isn't for performance analysis. You build it to see if your whole project is heading in the right direction, because if it isn't, any performance optimization is wasted time.

If the direction is right, the prototype next shows you not how to make the design efficient, but whether efficient design is actually needed. See, for example, the above-mentioned Minix mkfs example. In real projects, developers will have it much harder to "guess" how often functionality is used than with mkfs.

"If 'drying cement' keeps you from fixing problems, your project will have much more serious issues than performance."

What is that supposed to mean?

It means that if you detect performance problems late, you'd still fix them. Just as if you detect other fundamental design issues late, you fix them.

It means that if at a later point there are any we-won't-touch-that-part-anymore pieces in the project, and they are an obstacle to core functionality, you're doomed. So you don't build such pieces; you build pieces that can be changed even at a late point in the development cycle.

EDIT: I might add that this is becoming a bit off-topic A hobby OS doesn't have users, it does not have requirements, and maybe you optimize performance just for the fun of it. It does not make sense to ask whether performance is "sufficient" when nobody is actually using your OS for anything, so you rather optimize until you're satisfied with it.

EDIT: I might add that this is becoming a bit off-topic A hobby OS doesn't have users, it does not have requirements, and maybe you optimize performance just for the fun of it. It does not make sense to ask whether performance is "sufficient" when nobody is actually using your OS for anything, so you rather optimize until you're satisfied with it.

It depends ! If you plan to become king of the OS world, you also have to get the fastest OS, isn't it ?

(Myself, looking at the current kings of the hill, I think it's definitely not the case, but well...)

"Depends on the case, but yes, the first prototype *can* be a major investment. Point is, if you invest in anything else, your investment is most likely lost."

This is a generalization, what do you really mean here?

"A prototype then often shows you the right direction."

Of course.

"No. The prototype isn't for performance analysis. You build it to see if your whole project is heading in the right direction, because if it isn't, any performance optimization is wasted time."

Again, you are the one who brought the prototype into the discussion, no one here has said anything about needing to optimize the prototype.

What I did say was that it is important to analyze and predict potential efficiency problems with the design before getting so far into development that it's hard to change. As far as I can tell, your statements like the following seem to agree with my reasoning.

"If the direction is right, the prototype next shows you not how to make the design efficient, but whether efficient design is actually needed."

"See, for example, the above-mentioned Minix mkfs example. In real projects, developers will have it much harder to "guess" how often functionality is used than with mkfs."

I'd wager a guess that the Minux mkfs probably worked within one week and that the student was optimizing it afterwards for six months. If this is the case, then it's not really relevant to a discussion on early optimization. Either way, we agree this situation was ridiculous.

"It means that if you detect performance problems late, you'd still fix them. Just as if you detect other fundamental design issues late, you fix them."

But fixing them late can be magnitudes harder such that many projects simply give up on the notion of fixing them, please see my earlier examples.

"So you don't build such pieces; you build pieces that can be changed even at a late point in the development cycle."

Whether we like it or not, there comes a time in many projects where we pass a point of no practical return. For example the choice between threading, poll/select(), multi-process, or AIO is needs to be decided early on. No matter how good your final design is, it requires a great deal of effort to change models - every single IO point is potentially affected.

Sure it can be done, but those of us with optimization experience can void many performance problems such that we wont have to cross such bridges later on. Again, see my earlier examples.

I'm not talking about profiling each function or anything like that, is that what you're thinking? I'm really referring to optimizing the overall design for performance at a higher level.

"A hobby OS doesn't have users, it does not have requirements, and maybe you optimize performance just for the fun of it. It does not make sense to ask whether performance is 'sufficient' when nobody is actually using your OS for anything."

True, but sometimes those pet projects become famous and for better or worse the future has to deal with legacy decisions whether or not they were well thought out.