“The
Fundamental Rules” of Software Engineering
1) If you don’t do a system architectural design with well-defined interfaces, integration will be a big mess.
2) Design before coding.
3) If a project is late and you add more people, the project will be even later [3].
4) Team members that are new to a project are less productive (1/3 to 2/3 less) than the adequately trained people.
5) The average newly hired employee is about ½ as productive as an experienced employee [1].
6) Two factors that affect productivity are work force experience level and level of project familiarity due to learning-curve effects [1].
7) Developers’ productivity varies greatly depending on their individual skills (experience concerning a development activity, knowledge of the tools, methods, and notations used, etc.) [2, 4, 11].
8) Using better and fewer people is more productive than using more less qualified people [2]
9) The greater the number of developers working on a task simultaneously, the faster that task is finished, but more overall effort is required due to the growing need for communication among developers. Thus, the productivity of the individual developer decreases [2].
10) The earlier problems are discovered, the less the overall cost will be [7].
11) The error detection effectiveness of reviews depends greatly on the qualifications and preparations of the reviewers and the completeness and correctness of the documents used as a reference [14].
12) Reviews of non-technical documents (e.g., requirements specification, user manual) are more effective if the customer is involved [10].
13) Develop tests before doing the coding.
14) Extreme time pressure leads to decreased productivity [7].
15) Extreme time pressure leads to a faster rate at which errors are made, which leads to a further delay in the completion date [9].
16) Error correction is most efficiently done by the document’s author(s) [7].
17) The more errors a document from a previous phase contains, the more errors will be passed on to the next document [7].
18) Always test everything.
19) Talk to users, not to customers to verify the prototype.
20) Inspection is the most cost-effective measure of finding problems in software.
21) Software inspections find a high percentage of errors early in the development life cycle [13].
22) The use of inspections can lead to defect prevention, because developers get early feedback with respect to the types of mistakes they are making [13].
23) Every group has one programmer that is 10 times more productive than everyone else.
24) If you disable Internet surfing, productivity will go down.
25) The number of meetings is determined by the kinds of processes used.
26) Changing requirements are inevitable. Anticipating change with open architectures, adaptable designs, and flexible planning can help to mediate some of the ill effects of these changes [6].
27) Design for change/variability.
28) Use defensive programming.
29) Configuration management is good.
30) Successful software is designed by people who understand the application of the software (e.g., a well-designed missile control program was designed by someone who understood missiles) [8].
31) Software development requires a substantial time commitment to learning the application domain [5].
32) Broad application knowledge is acquired more through relevant experience than through training [5].
33) The more bugs you find, the more buggy the rest of your program will likely be.
34) Tests reveal errors in the code. The better a test is prepared for, the higher amount of detected errors.
35) Sticking with a too-tight schedule increases cost due to a large work force [1].
36) Motivation is increased through monetary incentives (profit sharing, pay for performance, merit pay, work measurement with incentives, and morale measurement), creating a positive frame of mind at work (employee involvement in wellness programs and creating fun at work), encouraging a feeling of commitment and responsibility (worker participation in decision-making, getting employees to think like owners, self-managing work teams, commitment to productivity breakthroughs, and providing an environment with more freedom and less restrictions), and increasing schedule pressure (using visible milestones and setting individual goals.) Increased motivation leads to increased productivity which reduces cycle time [13].
37) Improving the work environment is done by making ergonomic considerations, giving employees enclosed offices to reduce background noise and interruptions, and giving employees access to required resources, such as computers, software tools, support staff, and information. Improving the work environment leads to increased productivity, which reduces cycle time [13].
38) Getting the most out of employees can be done by utilizing experts, employee training, skills assessment and job matching, and reducing turnover. Getting the most out of employees leads to increased productivity, which leads to decreased cycle time [13].
39) Improving the software development process can be done by formalizing the process, controlling quality, and taking advantage of tools. Improving the software process increases employees’ motivation, which also increases their productivity [13].
40) Rework is usually due to customer requirements, product flaws, and communication breakdown between project members. Improving the process to reduce rework can be done by using prototyping and evolutionary development and by using formal specification methods, modern programming practices, and inspections. Reducing rework increases productivity [13].
41) Design complexity can be reduced by using object-oriented design techniques. Reducing design complexity reduces product complexity, which increases productivity [13]
42) Code complexity can be reduced by using modularization and object-oriented programming techniques. Reducing code complexity reduces product complexity, which increases productivity [13].
43) Cognitive complexity can be reduced by modularization, multiple levels of abstraction, simulation, and prototyping. Reducing cognitive complexity reduces product complexity, which increases productivity [13].
44) Test complexity can be reduced by using testing tools, building the product with testing in mind, and testing for the type of environment a product will be used in. Reducing test complexity reduces product complexity, which increases productivity [13].
45) Management complexity can be reduced by using project management planning tools and methods. Reducing management complexity reduces product complexity, which increases productivity [13].
46) Tasks can be eliminated or simplified by using automation of tasks (e.g., code generators, automated testing) and eliminating non-value added activities and low-priority tasks. This leads to increased productivity [13].
47) Nine ways to reduce cycle time are: increase productivity, reduce rework, maximize software reuse, reduce product complexity, eliminate or simplify tasks, maximize task concurrency, reduce undiscovered work, reduce risk, and use process models aimed at cycle time reduction [13].
48) Productivity is increased by increasing motivation, improving the work environment, getting the best people for the job, improving the process, and maximizing reuse [13].
49) Product complexity can be reduced by reducing code complexity, design complexity, cognitive complexity, test complexity, and management complexity [13].
50) Decisions made in the upstream portion of the software development process (requirements and design) impact productivity, quality, and costs throughout the life cycle more than the other portions [5].
51) The thin spread of application domain knowledge is a major phenomenon that greatly reduces software productivity and quality [5].
52) Specification mistakes often occur when designers do not have sufficient application knowledge to interpret the customer’s intentions from the requirements document [5].
53) Requirements will appear to fluctuate when the development team lacks application knowledge and performs an incomplete analysis of the requirements [5].
54) Coordinating understanding of an application and its environment requires constant communication between customers and developers [5].
55) Specifications are almost always incomplete and fraught with ambiguities. Constant contact with the customer is required to obtain the correct requirements. Without this communication, the developers tend to make incorrect assumptions about what the customer wants [6].
56) Fluctuating and conflicting requirements is a major phenomenon that greatly reduces software productivity and quality [5].
57) Communication and coordination breakdown is a major phenomenon that greatly reduces software productivity and quality [5].
58) Truly exceptional designers that are extremely familiar with the application domain, skilled at communicating their technical vision to other project members, possess an exceptional ability to map between the behavior required of the application system and the computational structures that implement the behavior, and are recognized as the “intellectual core” of the project are a scarce resource [5].
59) New requirements frequently emerge during development since they could not be identified until portions of the system had been designed or implemented [5].
60) Besides a developer’s ability to design and implement programs, his skills in resolving conflicting requirements, negotiating with the customer, ensuring that the development staff shares a consistent understanding of the design, and providing communications between two contending groups are crucial to project performance [5].
61) Undiscovered work (work that was not considered in initial planning estimates) can be reduced by using formal methods, analysis of PERT sizing metrics, the Spiral life cycle model, and prototyping. Reducing undiscovered work leads to increased productivity [13].
62) Risk can be reduced by using risk management techniques. Reducing risk leads to increased productivity [13].
63) Inspections should be thought of as part of the development process, and time must be set aside accordingly. Once this is done, inspections can have a significant improvement in the development organization’s ability to meet internal schedules [13].
64) Proper use of inspections can even shorten life cycle [13].
65) Participants in the inspection team get a high degree of product knowledge, which leads to higher productivity [13].
66) Slower programmers show a great deal of improvement when using inspections [13].
67) A new project assignee does not become productive until six months to a year into the project [5].
68) Collaborators use hand gestures to uniquely communicate significant information [12].
69) Employers often limit the number of hours employees can work, resulting in further pressure to finish a project as quickly as possible [6].
70) The customer often changes deadlines to be earlier than originally agreed-upon, requiring negotiation with the customer for either allowing some deliverables to be delivered at the earlier date, with the rest being delivered later, or dropping some deliverables or requirements altogether [6].
71) Code comments and documentation are often produced at the end of a project, creating major problems when a team member is lost at short notice, leaving others to continue their work. This can be alleviated by having quality auditors require inspections at very short notice [6].
72) Teams often change during projects (members are added and/or removed.) [6].
73) Sometimes the software used for development is upgraded to a new version during development, and despite claims that it is fully backward-compatible and won’t affect their work, it usually introduces new problems [6].
74) Hardware crashes, and customers are often unsympathetic to this kind of delay [6].
75) When a project is in its later stages of development, the development hardware and software tend to be under the greatest demand, and performance starts to suffer with lengthy compilations, builds, and test runs [6].
76) Matching the tasks to the skills and motivation of the people available increases productivity [2].
77) Employee motivation is the strongest influence of productivity [2].
78) Above a certain threshold, work conditions are not a powerful motivator, but below that threshold, they are a powerful de-motivator [2].
79) The training of new employees is usually done by the “old-timers,” which results in a reduced level of productivity on the “old-timer’s” part. Specifically, on the average, each new employee consumes in training overhead 20% of an experienced employee’s time for the duration of the training or assimilation period [1].
80) The average assimilation delay, the period of time it takes for a new employee to become fully productive, is 80 days [1].
81) As schedule pressure increases, quality assurance activities (especially walk-throughs and inspections) are often relaxed or suspended altogether [1].
82) In the absence of schedule pressure, a full-time employee allocates, on average, 60% of his working hours to the project (the rest is slack time: reading mail, personal activities, non-project related company business, etc.) [1].
83) Under schedule pressure, people tend to increase their percentage of working hours spent on the project by as much as 100%, due to spending less time on off-project activities, such as personal business and non-project communication, and/or working overtime [1].
84) The three “resource-type” variables that have the greatest impact on programmer productivity are the availability of programming tools, the availability of programming practices, and programmer experience [1].
85) The two “task-type” variables that have the greatest impact on programmer productivity are the programming language and the quality of external documentation [1].
86) The average full-time employee misses 13 – 15 days of work per year (not counting vacation time). Reasons are broken down in the following table [Godwins., 1996 #1239]:
|
Reasons for Missed
Work Day |
All Employees |
Employees with
Dependents |
|
Stress |
1.1 |
1.1 |
|
Personal Matters |
1.4 |
1.5 |
|
Sick Child |
1.2 |
2.1 |
|
Day Care Availability Issue |
0.4 |
0.8 |
|
Elder Parent Care |
0.6 |
0.9 |
|
Other Family Matters |
4.4 |
4.6 |
|
Sick/Illness |
4.5 |
4.2 |
|
Total Annual Downtime (days) |
13.6 |
15.2 |
1. Abdel-Hamid, T. and S.E. Madnick, Software Project Dynamics: an Integrated Approach. 1991, Upper Saddle River, NJ: Prentice-Hall, Inc.
2. Boehm, B.W., Software Engineering Economics. 1981, Upper Saddle River, NJ: Prentice Hall, Inc.
3. Brooks, F.P., The Mythical Man-Month: Essays on Software Engineering. 2 ed. 1995: Addison-Wesley. 336.
4. Bryan, G.E., Not All Programmers are Created Equal, in Software Engineering Project Management, R.H. Thayer, Editor. 1997, IEEE Computer Society: Los Alamitos, CA. p. 346-355.
5. Curtis, B., H. Krasner, and N. Iscoe, A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 1988. 31(11): p. 1268-1287.
6. Dawson, R., Twenty Dirty Tricks to Train Software Engineers, in Proceedings of the 22nd International Conference on Software Engineering. 2000, ACM. p. 209-218.
7. Drappa, A. and J. Ludewig, Simulation in Software Engineering Training, in Proceedings of the 22nd Internation Conference on Software Engineering. 2000, ACM. p. 199-208.
8. Humphrey, W.S., Managing the Software Process. 1990: Addison-Wesley.
9. Levary, R.R. and C.Y. Lin, Modelling the Software Development Process Using an Expert Simulation System Having Fuzzy Logic. Software -- Practice and Experience, 1991. 21(2): p. 133-148.
10. Pressman, R.S., Software Engineering -- A Practitioner's Approach. 4 ed. 1997, New York, NY: McGraw-Hill.
11. Sackman, H., W.J. Erikson, and E.E. Grant, Exploratory Experimental Studies Comparing Online and Offline Programming Performance. Communications of the ACM, 1968. 11(1): p. 3-11.
12. Tang, J.C., Findings from Observational Studies of Collaborative Work, in Readings in Groupware and Computer-Supported Cooperative Work, R.M. Baecker, Editor. 1990, Morgan Kaufmann: San Mateo, CA. p. 251-259.
13. Tvedt, J.D., An Extensible Model for Evaluating the Impact of Process Improvements on Software Development Cycle Time. 1996, Ph.D. Dissertation, Arizona State University.
14. Weller, E.F., Lessons from Three Years of Inspection Data. IEEE Software, 1993. 10(5): p. 38-45.