When it comes to programming, regardless of the platform, certain rules apply. One of which is a design document. I am not saying a program cannot be developed without a design document and on the other hand I am not saying a design document must be complicated explaining every step of the program you are developing. In fact, the design document should be simple and broad. It should help you communicate your intentions for your program and provide a general direction of the development process.
When you look at a good painting, the artist uses colors, brush strokes and angles to bring your attention from the broad view of the painting to the focal point of the painting so you understand what he / she is trying to represent. The same should be true for your design document. On many occasions I have created a design document for a program I was developing on a yellow legal pad. It starts with a goal of what I expected the application to do. Then I added a general overview of the necessary objects in the application to accomplish the goal. Finally I would sketch a view of the expected screen shots the program would need for user interface. That’s it.
Don’t get caught in the trap of thinking your document must reflect what you have built. On the contrary; it should only reflect what you intend to build. Save the details for the system document or project tracker worksheet.
Let us know what you think on this matter.
Leave a comment