Sunday, December 5, 2010

Lessons Learned From OS

OS was defeated last night. It was amazing. And we only had to stay up to 5am and go through ~450 broken builds! As I mentioned earlier, OS teaches you a lot about programming. You will come out a much better programmer, though not because you know how an OS works.

Here's the things I learned during this crazy project:

- Planning out everything before development is a really good idea. You should not be programming before you know how all the parts will interact. If that's not possible, you should take time to make your implementation very flexible, since it might have to change (sometimes radically).

- Pair programming is a good idea. Especially at 4am when you are both only half awake. We caught a lot of potential errors this way. We found pair programming especially useful for A3, since the work didn't really divide up very well.

- Overworked developers do sketchy things. After the 13th consecutive hour of development and debugging, you will do just about anything to get the job done. We definitely ignored some engineering "best practices" during our development.There are certainly sketchy solutions in our code. If we were maintaining the OS later, now would be a good time to re-factor everything.

- Debugging is hard and will take you double the time you allocate for it.

- A girlfriend that make you an OS care package(with BACON!) at 2am is amazing.

- Finally getting everything done is very satisfying and worth the trouble.

- Assert those stupid things that you think can never happen. They will happen and cost you hours of frustrating debugging time.

- Tests suites are invaluable. It's even better if you can run them all in under a minute.

- Bitmaps can do some things blazingly fast.

- Your physical memory manager probably shouldn't give it's own frames to other processes. This will end poorly for your physical memory manager.

- Low level programming sucks.

- C sucks. 

What did you learn from OS or other crazy workload projects? Technical or otherwise.

Now it's time to finish up DB and sleep for 8294534529 hours. Wooo!


  1. Understand what something is supposed to do before you make it..

    we completely misunderstood what the purpose of our coremap was (i had no idea, so i trusted what was suggested without researching myself) and it ended up costing us pretty much everything >_<

    related to this, something you are sure is correct, can be wrong.