Software Developer's GuidebookDaniel R. Mitchell Chapter 1: IntroductionThis book contains a collection of essays about software development based on my own experiences. It began as a series of "notes to self" about things I had learned and wanted to remember. The act of writing it down and expanding on the notes forces me to think these things through and increase my own understanding. I also hope that others may find the ideas useful. Chapter 2: A Proper Mental AttitudeIn ancient Rome, so it is said, an architect was required to stand underneath the arch he designed as the scaffolding was removed. If he didn't do his job right, the arch would collapse on top of him. This has been called The Tremble Factor. Chapter 3: TaxonomySoftware is not all alike nor is all software written for the same purpose. To understand the issues in software development we need to first identify the different categories of software that might be developed. Chapter 4: GoalsThere are two important goals for software developers:
Both goals must be met in order to be successful. Everything done during development should be aimed at one of the goals. Chapter 5: DesignWe often speak of software design as "software engineering." This is unfortunate since software design is not precisely equivalent to engineering. As software developers, we do not work with physical things that can be measured to determine their structural capabilities. Because it is not physical, software is perceived as infinitely malleable. Coding is perceived as just "typing at the computer" and we are expected to be able to alter the system significantly at any time. We must construct a system that is sufficiently rigid to be reliable, but flexible enough to be adaptable. Almost no other discipline has this problem. It is more accurate to describe software design as a process of modeling. We describe the user's data and the processing to be performed on the data by creating a model of that data and processing. We then attempt to reduce that model to its most concise form. This is, in essence, a form of applied mathematics and should be treated as such. Chapter 6: Project Life CycleThe project life cycle defines the steps needed to produce a piece of software from start to finish. Chapter 7: Estimates and SchedulingFor a variety of reasons, software development schedules are notoriously inaccurate. In some cases the problem can be attributed to poor management practices. The managers don't factor in all the things they should, fail to schedule tasks based on a critical path, don't keep track of progress, and often have no metrics of earlier projects to guide them in making estimates. Thus, an estimate of the project's completion is no more than a wild guess. (I heard a manager at a large, well-known software company once say that it's all "magic" anyway. With that type ofattitude, I doubt that he will ever ship a product on schedule.) Although some schedule problems are inherent in the way we develop software, estimating software schedules can be improved by using more accurate estimating techniques. Chapter 8: Teams and CommunicationsAlmost all software is created by a development team. The size and complexity of the system and the time allowed for development are usually the basis on which the team is assembled and staffed. It's important to get the right mix of team members for the project and to insure that all team members can work together. The first step to take in creating a team is to analyze and understand the roles and responsibilities of team members. The members of the team are then selected and assigned duties to fulfill the various roles. Some projects may not need all team roles to be filled. The team manager will have to determine who is needed and when. Cost and time constraints will also affect selection of the team members. Chapter 9: Development ToolsA software developer has a wide range of tools to assist in creating the software. It is vitally important to know what tools are available and how to use the tools effectively. |