Co-dependent Parts
In an article about mistakes a startup can make, Paul Graham writes:
Think about the overall goal, then start by writing the smallest subset of it that does anything useful. If it’s a subset, you’ll have to write it anyway, so in the worst case you won’t be wasting your time. But more likely you’ll find that implementing a working subset is both good for morale and helps you see more clearly what the rest should do.
I found this interesting simply because it has been my strategy for tackling our Realtime Operating Systems project this term. No individual piece of the project is particularly difficult, but it is a little tricky to map out a plan for incrementally developing it.
It’s obvious that certain auxiliary things can be bolted on later, but the majority of the assignment has to be in place before it does much of anything at all.
My approach? Get the major bits running in entirely separate, proof-of-concept programs. One group member is implementing a simple text parser, another the IRQ system, and I’m working with the final person on the switching stuff. There will still be an awkward moment when these parts have to be glued together, but at least each component will be known to function correctly on its own.





