This post does not tutor any specific methodology or design approach to any project but more of a note to self. Its been 4 years since I left undergrad school and since then and before have been involved with several projects of various magnitudes. In most of these projects I found myself get stuck at exactly similar scenarios and recently figured out the reason for that. The reason is “Getting into the Nitty-gritty of things too early”. Thanks to my mentors Dr. Philip Brisk and soon to be (Dr) Theo Kluter  at EPFL and Dr. Joel Sherrill and Thomas Doerfler (he doesn’t blog nor have a page that I know of) as mentors for my Google Summer of Code project for the help they have extended in my path to gain more knowledge in the field. The below thoughts are mostly based on Real Time systems and advanced computer architecture projects I have been involved in.

Most often when we start a project, we get a very generic picture , read around the project’s required literature background and immediately get into the “details” of the system a bit too fast without “completely” getting a grip on the Functional Overview of the system. Many people do the documentation (including explaining the design structure, functional flow) after coding a basic prototype and this itself in my opinion is a flaw. I found it much better to do the reverse and found most successful “engineers” do that way. There have also been scenarios where people have asked me “You draw a structural representation of your system before implementing??” which I find very amusing. How can one get something done without having a picture on paper first?

So the first thing I do now when starting off on a new project is to get a very high abstract picture of the requirements of the project. Then a bit more digging into the “functionality”. It more or less can be compared to a behavioural modeling of the project. Something like this  . Note that the picture does not have any details of implementation (like which function to call, in what module will the implementation go into, what parameters to pass, which module is reusable etc etc). Its just plain functional diagram. This in my opinion helps one to cover most use cases, error scenarios. Its much easier to handle or think about these scenarios at a high level. Believe me, its just too easy to get into the nitty gritty and start putting down the details. Slap yourself and come out of that once you find yourself doing it. The paradigm is that once you are into the details you lose track of the big picture and hence the wider scope and overlook several scenarios. Yes, of-course there will still be some scenarios overlooked but it would be less in number and much easier to handle.

Once most cases are covered one can now, start digging into the diagram and find out re-usable portions of a module easily by repeating flow diagrams, eliminate conditions etc. And then get into the low level design and coding aspect. Also having such a high level functional diagram in place gives rise to many test cases and ensures you test most common conditions before hand. I use Freemind for these diagrams. A great tool not only for mind mapping but also for such things.

It might sound very trivial, but how many of us have got stuck in the utter complexity of the system and miserably struggled to get ourselves out of the situation? If you have any other suggestions do feel free to leave a comment.