What is your favorite method to conceptualize a project?

Question

I'm running into the issue with a new project that is it starting to get difficult to contain the whole thing in my mind and move it around. While I still do this for the majority of programming, I know that physical means can help significantly.

What methods do you use?

The 3 ideas I can think of are:

1. Using Styrofoam balls to show class-relations (maybe more?)
2. Using a whiteboard to draw ideas out
3. Using some sort of software that helps map out your idea

Answer 1

Whiteboards / paper.

Usually paper - whiteboards have a habit of being wiped out by colleagues!

I've tried many times to use some sort of software to help in the design / planning stages, but I've yet to find a piece of software which makes this work.

Answer 2

Read through complete requirements(PRD) throughly. May be write it down your interpretation(ERD). Then take a whiteboard/paper,

• first draw high level blocks for your project.
• then you can expand these blocks individually further simplifing them.
• keep repeating these till you get all details noted from requirement covered.

There may be some softwares for same, but never used one.

Answer 3

I once interned at a company where we would write class names on a piece of paper and stick them on our foreheads. Pure foolishness. You only have two arms to represent interactions, and usually never enough developers to represent all of your classes. I'm surprised that we didn't wind up with God objects (read up on your anti-design patterns) due to lack of people!

A whiteboard and a erasable marker (NOT a Sharpie, I've seen this mistake before!) is the way to go for me. Understanding UML notation helps significantly when working in a team, since you're all using and understanding the same notations. Just don't get into debates about the correct notation, as that wastes valuable time!

Eventually you may want to move this into a program that can generate/update a skeleton framework for your code. Sometimes your IDE is enough (Visual Studio class diagrams), and other times you may want dedicated software that plugs into your IDE (Rational Software Architect w/ Eclipse).

As a word of advice on how to go about it... make sure that you (and any other teammates you may have) have a general understanding of the use cases. These don't necessarily need to be documented so long as you and your team have a thorough understanding of how your software will be used. If you are at all serious about your work, you will document these. Also, don't think that this all has to be done in order. Software design, like development, is iterative... although that's not to say that the process should be completely random and unstructured. The use cases will give you hints as to the classes you will need to create. For example, if "user registers an account" is a use case, you already know that you'll need a class to represent an account. If when creating the account you realize that the user can add a billing address and a shipping address, each with a street name, postal code (Canada ftw), and phone number, you'll know that you need an Address class.