As a student in high school, I struggled when writing papers. I had a lot to say, but the resulting jumble of thoughts and ideas was poorly presented and confusing to the reader. A ninth grade teacher hammered me for this, and ultimately taught me that no article or paper could be successful if it lacked a logical organization. He preached the concept of first creating an outline to assemble the main concepts in a meaningful and logical way, and THEN fleshing out the paragraphs. This is a lesson I never forgot, and as I got into automation, I realized this same approach is just as critical to any kind of software development.
Concept: This applies to any major undertaking (such as writing a paper, making a presentation, or designing complicated batch code). Take the time to lay out a design and get the underlying structure right before you begin. You will save yourself hours of wasted effort, and your work product will be much more cohesive.
Details: When faced with a major creative endeavor, most people want to jump in and get started so they can feel that they are making progress. They sit down and immediately start writing/painting/banging out lines of software code. This method can eventually work, but the path to success will be a circuitous one full of wrong turns and rework.
Save the team a lot of wasted effort, and take the time to work out a solid framework before starting on the details. This concept applies to any major project but is especially true for software development. If you first outline the major components and think through how the parts will interact, the resulting code will be much simpler and testing and start-up will go infinitely smoother. Resist the urge to just sit down and bang out code. Many a project team has failed to do this and has blown the entire labor budget trying to patch and cobble something together only to ultimately step back, toss all the work done to date, and effectively start all over.
Once the design is complete, document it in a manner that is clear and unambiguous to the project team. The form of the documentation will vary depending upon the project size and type, but regardless, the documentation should be easily read and understood and easily updated as the project progresses to completion. This same documentation can be used for testing and checkout purposes at the end of the project and provided to the customer for future reference.
Watch-Outs: Due to tight schedules, many project managers encourage “concurrent engineering,” in which multiple teams are working simultaneously rather than sequentially. Fight the urge to let the programmers “get started” while another group is working out the software design details. If the programmers are allowed to begin in advance with no direction, much of their work product will ultimately have to be reworked or simply abandoned. When multiple people or vendors are part of project, spend extra time defining the boundaries where these groups interface. This is a common failure area of large projects.
Exceptions: Concurrent engineering is possible if it is done correctly. One portion of the design can be completed and released for detailed software development while the other areas are being designed and outlined. Keeping everything straight can be difficult, but it can work if the team communicates well.
Insight: This same advice is invaluable for writing a paper or creating a presentation. A simple outline will help focus the paper and make for a much more understandable document/talk. Start with a high level outline to list the concepts and the order of presentation, then add details to each section. Once a detailed outline has been created, converting it to a paper or talk is relatively easy because each line in the outline becomes a sentence or two in the final product.