Basic Principles of software development (II)-Typical errors

Most typical mistakes are attractive on the surface, giving people an attractive prospect, but generally cannot produce the expected results.

 

"Do you want to save projects that are lagging behind? ----Add more people to the project !"

 

The following lists 36 typical errors in terms of personnel, process, product, and technology.

Personnel

 

• Typical error 1: Dampen enthusiasm

Insufficient care and attention to personnel, excessive progress pressure, lack of incentives, and exaggerated incentives.

• Typical error 2: Low personnel quality

Poor personnel ability, low work efficiency, and even many mistakes.

• Typical error 3: Out of control for problematic employees

Taking measures against problematic personnel is the most common complaints from project team members.

• Typical error 4: Heroism

Emphasizing personal heroism can lead to additional risks and weaken cooperation among multiple roles in the software development process.

• Typical error 5: Project Personnel added later

Blindly adding people to the project later stage is equivalent to adding fuel to the fire.

• Typical error 6: The office environment is crowded and noisy.

People with quiet and hidden office environments often have better performance than those working in noisy and crowded environments.

• Typical error 7: Friction between developers and customers

The main reason is the lack of communication. This friction takes time, and it will shift the attention of both the client and the developer on the project work.

• Typical error 8: Unrealistic expectations

Too high expectations and subjective and unrealistic ideas. It is one of the common causes of friction between developers and customers or project managers.

• Typical error 9: Lack of effective project support

All aspects of software development projects require high-level support, including actual planning, change control, and adoption of new development methods. Lack of effective high-level support is actually doomed to project failure.

• Typical error 10: Lack of the concerted efforts of various roles

All major personnel in software development must work together to focus on projects, including senior support, project leaders, project members, marketing personnel, end users, customers, and any project participants.

• Typical error 11: Lack of user intervention

Projects without early user intervention are at risk of misunderstanding of requirements and are vulnerable to the spread of functions in the later stages of the project.

• Typical error 12: Politics is higher than material

"Politicians" projects emphasize "Management first" and focus on their relationship with managers. Putting politics above results can cause great harm to software projects.

• Typical error 13: Full of imagination

Close your eyes and hopefully something will work as you would expect. Many software development problems are caused by imagination.

 

Example:

• The project team does not know if they can finish the project on time, but they think that if everyone can work harder and there is no problem, they should be able to complete the project.
• We don't need to demonstrate the latest changes to the customer. We are sure this effect is what the customer wants.
• The project team missed a milestone for several days. They said they would work harder to catch up with the next milestone. I think they can catch up with it in time.

  Stopover  

• Typical error 14: An overly optimistic plan

Creating an overly optimistic project plan is equivalent to drawing the bottom line for project failure, which leads to shortening analysis, design, and other key preliminary development activities. It also puts additional pressure on developers, it will cause huge damage to developers' self-confidence and productivity for a long time.

• Typical error 15: Insufficient risk management

If you do not take the initiative to manage risks, the risks will come to you at any time to disrupt your development plan.

• Typical error 16: Contractor-caused failure

If the contractor is not properly managed, the delivery may be postponed and the quality is difficult to guarantee.

• Typical error 17: Lack of plans

A project without a plan is like a boat floating in the ocean. No one knows where it will be.

• Typical error 18: Give up the plan under pressure

Many project teams have customized their plans, but they have to give up when they have trouble. The reason for project failure is not to discard the plan itself, but not to revise the plan in time to develop an alternative plan and put it into coding and problem handling.

• Typical error 19: A waste of time at the beginning of a fuzzy Project

The development plan is compressed due to the long time spent on preliminary work such as approval and budget, or the infinite circulation of demand. It is easier, cheaper, and less risky to save weeks or months of time in the early stage of the project than to compress the development plan.

• Typical error 20: Pre-activities do not meet the requirements

Research data:

Activities or jobs that are skipped in the early stage usually start with 10X to 100. If a job requires 5 at the beginning of the projectYou need at least 50Hours to complete it. (Fagan 1976, Boehm and papaccio 1988)

• Typical error 21: Poor design

Poor design is a special case where pre-activities do not meet requirements. High-pressure environments lead to a lack of careful design, which often leads to poor design.

• Typical error 22: Lack of quality assurance measures

Research data:

Cut down 1 in the early stage of the projectDay-to-day quality assurance activities will require threeTo 10The processing cost of the day. (Jones 1994)

• Typical error 23: Lack of management control

The lack of management control points makes it difficult to track the phases and states of the project. Therefore, it is difficult to know whether the project is on a normal track.

• Typical error 24: Integration that is too early or too frequent

When building an incomplete lock, premature integration or additional integration is not conducive to the product. It is just a waste of time and prolong the progress.

• Typical error 25: Missing necessary tasks during project estimation

Training, company and department meetings, technical review meetings, and other activities are often missed during project estimation.

• Typical error 26: Catch-up plan

When the progress lags behind, you do not re-check the task and adjust the plan, but simply decide to catch up with the progress.

In another case, when the product changes, the corresponding plan is not adjusted.

• Typical error 27: Reckless code

There is not enough demand base and clear Architecture Design for "side code side modification", resulting in too much repetitive work and rework, so that most projects end up failing.

 

Product

 

• Typical error 28: Gold Plating on demand

The project's product requirements require more product features or complex features than the actual needs, but do not allocate enough time to the schedule.

• Typical error 29: Function spread

During the entire development process, there will be an average of 25% demand changes for the project, with at least 25% impact on the software plan. If customers are allowed to constantly propose new requirements, the project will not be completed.

• Typical error 30: Gold Plating for developers

Developers are fascinated by new technologies and sometimes eager to use them in their own products, regardless of whether they are suitable or will damage the system as a whole.

• Typical error 31: Pushed and pulled transactions

The manager approves delayed projects, but adds new tasks to the projects.

• Typical error 32: Research-oriented development

The software development progress can be predicted for all reasons, and the software research progress is even unpredictable in theory. The same way of working as software research cannot be used to guide the project development.

 

Technical Skills

 

• Typical error 33: Silver Bullet syndrome

Over-Trust in some technical propaganda (some development process, someProgramDesign method, a development language), lack of necessary information to use these tools in a specific environment. When the team hopes to use them to solve the progress problem, it will inevitably fail.

• Typical error 34: Overestimating the savings caused by new technologies or methods

No matter how many new tools or methods are used, and how good these tools or methods are, they rarely greatly increase productivity. Software development consists of multiple tasks. A specific tool or method can only improve the production efficiency of a specific task. At the same time, their efficiency is often offset by the time they spend learning them.

• Typical error 35: Intermediate project switching Tool

Replacing tools in the middle of a project completely offsets the benefits of the new tool from the process of learning and mastering the new tool, repetitive work, and unavoidable errors.

• Typical error 36: Lack of automaticSource codeControl Means

Lack of automatic sourcesCodeControl may easily cause version conflicts, lost versions, and lost updates, and waste a lot of time to deal with these problems.

 

Coming soon: Basic Principles of software development (III)-Basic Principles

Codeproject