Top 10 Traits of Highly Successful People -That You Can Learn!
By Philip E. Humbert
We have all read about people who are successful briefly. They win a gold medal, make a fortune, or star in one great movie…and then disappear. Or, there are those like Marilyn Monroe and Howard Hughes who achieve extraordinary success, at the cost of their own lives. These examples do not inspire me!
My focus and fascination is with people who seem to do well in many areas of life, and do it over and over through a lifetime. In entertainment, I think of Paul Newman and Bill Cosby. In business, I think of Ben and Jerry (the ice cream moguls), and a local hardware store owner who is famous for the money he’s give to children’s charities. As a Naval Officer, husband, businessman, politician and now as a mediator and philanthropist on the world stage, Jimmy Carter has had a remarkable life. We all know examples of people who go from one success to another.
These are the people who inspire me! I’ve studied them, and I’ve noticed they have the following traits in common:
They work hard! Yes, they play hard, too! They get up early, they rarely complain, they expect performance from others, but they expect extraordinary performance from themselves. Repeated, high-level success starts with a recognition that hard work pays off.
They are incredibly curious and eager to learn. They study, ask questions and read – constantly! An interesting point, however: While most of them did well in school, the difference is that they apply or take advantage of what they learn. Repeated success is not about memorizing facts, it’s about being able to take information and create, build, or apply it in new and important ways. Successful people want to learn everything about everything!
They network. They know lots of people, and they know lots of different kinds of people. They listen to friends, neighbors, co-workers and bartenders. They don’t have to be "the life of the party", in fact many are quiet, even shy, but they value people and they value relationships. Successful people have a rolodex full of people who value their friendship and return their calls.
They work on themselves and never quit! While the "over-night wonders" become arrogant and quickly disappear, really successful people work on their personality, their leadership skills, management skills, and every other detail of life. When a relationship or business deal goes sour, they assume they can learn from it and they expect to do better next time. Successful people don’t tolerate flaws; they fix them!
They are extraordinarily creative. They go around asking, "Why not?" They see new combinations, new possibilities, new opportunities and challenges where others see problems or limitations. They wake up in the middle of the night yelling, "I’ve got it!" They ask for advice, try things out, consult experts and amateurs, always looking for a better, faster, cheaper solution. Successful people create stuff!
They are self-reliant and take responsibility. Incredibly successful people don’t worry about blame, and they don’t waste time complaining. They make decisions and move on. Sometimes they are criticized for taking this to extremes – Jimmy Carter carried his own briefcase and a President "shouldn’t" do that! Extremely successful people take the initiative and accept the responsibilities of success.
They are usually relaxed and keep their perspective. Even in times of stress or turmoil, highly successful people keep their balance, they know the value of timing, humor, and patience. They rarely panic or make decisions on impulse. Unusually successful people breath easily, ask the right questions, and make sound decisions, even in a crisis.
Extremely successful people live in the present moment. They know that "Now" is the only time they can control. They have a "gift" for looking people in the eye, listening to what is being said, enjoying a meal or fine wine, music or playing with a child. They never seem rushed, and they get a lot done! They take full advantage of each day. Successful people don’t waste time, they use it!
They "look over the horizon" to see the future. They observe trends, notice changes, see shifts, and hear the nuances that others miss. A basketball player wearing Nikes is trivial, the neighbor kid wearing them is interesting, your own teenager demanding them is an investment opportunity! Extremely successful people live in the present, with one eye on the future!
Repeatedly successful people respond instantly! When an investment isn’t working out, they sell. When they see an opportunity, they make the call. If an important relationship is cooling down, they take time to renew it. When technology or a new competitor or a change in the economic situation requires an adjustment, they are the first and quickest to respond.
These traits work together in combination, giving repeatedly successful people a huge advantage. Because they are insatiable learners, they can respond wisely to change. Because their personal relationships are strong, they have good advisors, and a reserve of goodwill when things go bad. And finally, none of these traits are genetic! They can be learned! They are free and they are skills you can use. Start now!
Saturday, July 18, 2009
Thursday, August 7, 2008
The Fundamental Rules” of Software Engineering (Courtesy : http://www.ics.uci.edu)
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
References
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.
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
References
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.
Subscribe to:
Posts (Atom)