42 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.
🧵
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.
4) Team members that are new to a project are less productive (1/3 to 2/3 less) than the adequately trained people.
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.
6) Two factors that affect productivity are work force experience level and level of project familiarity due to learning-curve effects.
6) Two factors that affect productivity are work force experience level and level of project familiarity due to learning-curve effects.
7) Developers productivity varies greatly depending on their individual skills (experience concerning a development activity, knowledge of the tools, methods, and notations used, etc.).
8) Using better and fewer people is more productive than using more less qualified people.
8) Using better and fewer people is more productive than using more less qualified people.
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.
10) The earlier problems are discovered, the less the overall cost will be.
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.
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.
12) Reviews of non-technical documents (e.g., requirements specification, user manual) are more effective if the customer is involved.
13) Develop tests before doing the coding.
13) Develop tests before doing the coding.
14) Extreme time pressure leads to decreased productivity.
15) Extreme time pressure leads to a faster rate at which errors are made, which leads to a further delay in the completion date.
15) Extreme time pressure leads to a faster rate at which errors are made, which leads to a further delay in the completion date.
16) Error correction is most efficiently done by the document’s author(s).
17) The more errors a document from a previous phase contains, the more errors will be passed on to the next document.
18) Always test everything.
17) The more errors a document from a previous phase contains, the more errors will be passed on to the next document.
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.
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.
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.
23) Every group has one programmer that is 10 times more productive than everyone else.
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.
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.
27) Design for change/variability.
28) Use defensive programming.
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).
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).
31) Software development requires a substantial time commitment to learning the application domain.
32) Broad application knowledge is acquired more through relevant experience than through training.
32) Broad application knowledge is acquired more through relevant experience than through training.
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.
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.
36) Motivation is increased through monetary incentives. Increased motivation leads to increased productivity which reduces cycle time.
36) Motivation is increased through monetary incentives. Increased motivation leads to increased productivity which reduces cycle time.
37) Improving the work environment leads to increased productivity, which reduces cycle time.
38) Matching the tasks to the skills and motivation of the people available increases productivity.
38) Matching the tasks to the skills and motivation of the people available increases productivity.
39) Above a certain threshold, work conditions are not a powerful motivator, but below that threshold, they are a powerful de-motivator.
40) The average assimilation delay, the period of time it takes for a new employee to become fully productive, is 80 days.
40) The average assimilation delay, the period of time it takes for a new employee to become fully productive, is 80 days.
41) As schedule pressure increases, quality assurance activities (especially walk-throughs and inspections) are often relaxed or suspended altogether.
42) 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.).
Loading suggestions...