Hobby OS-deving 1: Are You Ready?
Linked by Hadrien Grasland on Fri 28th Jan 2011 20:37 UTC
OSNews, Generic OSes 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.
E-mail Print r 16   · Read More · 89 Comment(s) http://osne.ws/iq6
Permalink for comment 460264
To read all comments associated with this story, please click here.
RE[14]: Machine language or C
by Morin on Mon 31st Jan 2011 07:02 UTC in reply to "RE[13]: Machine language or C"
Morin
Member since:
2005-12-31

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.

Edited 2011-01-31 07:07 UTC

Reply Parent Score: 2