Setup the Playground 1st!

Before starting any development project, start by envisioning the perfect environment in which you want to develop said project.  If this environment does not exist, start by creating it - then move on to the project at hand.  Any services, features, helper methods/functions that can be handled abstractly by the environment should be considered 1st.  Only after "the playground" infrastructure has been setup - then move onto the actual project at hand.

The interesting thing about this process is that it is completely recursive, from a large - think operating system scale project - all the way down to an individual line of code.  Literally (as in, the literal definition of literally - not the figurative one!)

In other words, you're going to develop an operating system.  This system will need a file system, memory management, process management, thread management, etc. ... eventually.  But to begin with, whichever of these features are implemented, all operating systems need a bootstrap module.  You (definitionally) can not have an operating system without a bootstrapping function.

So, let's start by designing the much smaller concept of a simple kernel.  Not the final, full OS level kernel - but just the smallest kernel that I can think of.  i.e. If we were given 12 hours to write an OS - could we develop a kernel that could bootstrap a piece of hardware to some sort of "operational" state in 12 hours?  Even though I've never done anything even remotely like this before, I think that with the appropriate training, I could create a kernel in 12 hours.

In fact, there are probably 5 or 6 different ways that a "kernel" could be written.  This is where the creative/editing/design process really kicks into gear.  Because, now (hopefully as just a thought experiment at this point), each of the different approaches can be considered, in the larger context of the 6 months full OS development project that we're actually working on.  Most likely 1 or 2 of these models will show a substantial benefit over the others.

These 2 now become "finalists" as the potential model for our kernel.  At this point, it probably makes the most sense to just pick one and give it a try.  Within the first 3 hours, we hopefully have something productive.  In fact, we probably have enough to be able to really (in depth) re-evaluate our direction, and make sure that our assumption about the two finalists was accurate.  Often at this point in the process, it becomes absolutely apparent that the other approach (or possibly, even one of the 3 that was originally discarded) is actually a much better way to solve this problem.

The key to note at this point in the process is that it's REALLY cheap to switch completely the design at hand.

If we take the full 12 hours before we re-evaluate we're already pretty "locked in" to the design that we started out with.  Be open to change.  Be ready for the fact that many to most of the decisions that you make might be wrong (fail!).  But if you're open to that idea, you're much more likely to recognize the failure, and change course, early!