1. The first requirement for software delivery is quality, and there is no compromising on quality and on-time delivery.
  2. There are many kinds of the definition of high quality, for users who want to work pressure environment, high quality means that the response time and high capacity, for project cost sensitive, high quality on behalf of the low cost of development, for the customer, high quality means to meet all their needs, and have not perceived needs, but the above is not possible at the same time compatible, we will in accordance with the.
  3. Productivity is inversely proportional to quality, the higher the productivity, the lower the quality, the higher the quality, the lower the productivity,
  4. Quality software requires a high price. IBM gave NASAS software $1000 per line of code and less than one bug per 10,000 lines. It is feasible for developers to improve software quality.
  5. It is not feasible not to build quality at the beginning of the project, hoping to develop a random version and then renovate it to improve quality.
  6. Low reliability is worse than low efficiency. A program that consumes most of its execution time is low reliability, but it may not be discovered until long after the system is deployed. By the time it is discovered, the developer is long gone, and it is difficult to identify its cause.
  7. When the software is delivered, 20% of the resources should be spent to make a quick and dirty prototype, which should be delivered to the customer to collect feedback, and then requirements specifications should be written for development. In this way, we can know what the user wants as soon as possible, so as to prevent the product from being not what the customer wants and avoid wasting resources.
  8. More communication with users, understand the real needs, to solve the real problems, such a system, users will use.
  9. Why projects often fail, because customers and developers have different goals, for example, customers want is done during a certain period of time, can let the customer do sorting priority to the function, for developers, priority must be completed, the content of the intermediate completed reward, low-level needs very little reward, the extension will be punished.
  10. Plan to throw one away, you will throw it away anyway, it is said that if you make a brand new system, it is better to spend some resources to make the first version, maintain stability for a period of time, and then make the second version of the replacement.
  11. There are two types of prototype, disposable prototype and evolutionary prototype. When the core functions are not understood, a disposable prototype is made to give feedback to users. After the core functions are understood, evolutionary prototype is built.
  12. Build disposable prototypes. Build features you don’t understand. Disposable prototypes are built to master core features. When building evolutionary prototypes, you should build features that are already well understood, and if you build evolutionary prototypes that don’t clear the requirements, you’re making a mistake, and you’re moving further and further away from high-quality software.
  13. If you’re building a one-off prototype, do it as quickly as possible and don’t worry about quality.
  14. An effective, low-risk approach to software development is incremental expansion, where you start out with simple features and then expand bit by bit. If you start out with a complex system, you’ll have to refactor as you add features, which can be a nightmare.
  15. The more users see, the more they want. They should anticipate that customers will definitely put forward more requirements before delivery to users, and finally prepare countermeasures in advance.
  16. In the process of software development, the change of requirements is inevitable, and is throughout the beginning and end, it is best to add more time in the schedule to deal with the change of requirements, after all, because the change of requirements caused by the delay of the system is a gray area, it is difficult to get rid of.
  17. If possible, try to buy ready-made software, rather than develop from scratch, after all, ready-made software has been tested and verified by the market, if developed from scratch, not only the budget is easy to overvalue, but also cut functions in order to catch up with the schedule, and finally realize functions similar to the ready-made functions.
  18. Build good software, user manual as short as possible, the shorter the better the software design, there is no quick function of the trick, users actually do not want to spend a lot of time to learn those tricks, or try to make a simple general standard software. Just because a software developer likes a user interface doesn’t mean your customers will know how to use it. Many software developers like user interfaces with built-in tricks that can serve as shortcuts. In general, users want simple, clean, clear user interfaces, not gimmicks.
  19. It is wrong that there is a simple solution to every complex problem. Be highly suspicious of people who say this.
  20. Didn’t understand.
  21. Different languages are used in different scenarios, such as vue and React for the front end, Java and Go for the back end, Sketch for the design interface, and PS for the design of beautiful pictures. Because each language or tool has its own advantages over a particular domain.
  22. When building an automated scenario, do this manually. An undisciplined engineer with an excellent tool can become a dangerous undisciplined engineer. There must be basic discipline in using a tool, understanding and following the proper use of the tool. Do not use without discipline, in order to avoid overload phenomenon.
  23. CASE tools (integrated, labor-reducing tools that automatically cover all phases of the software development life cycle) can increase development productivity by 10-20%. Use them as much as you like, but be aware that the purchased tools may not be used. This is not because the tools are bad, but because they are not used well.
  24. CASE tools can make good engineers more efficient, mediocre engineers can only reduce the number of poor quality software, not mediocre engineers become good.
  25. CASE tools are expensive, so make them part of the cost of doing business. If they are not enough, consider the consequences, such as lower productivity, higher probability of customers not buying, and better staff mobility.
  26. Knowing when to use it is just as important as knowing how to use it. Knowing how to use a technology doesn’t make you a good engineer, but knowing when to use it does. Don’t use a technology just to use it.
  27. As soon as the requirements are met, you can stop doing more useless development. Each example consists of a series of steps. When half of the steps are completed and the problem is resolved, you can stop. The execution of the subsequent steps is not necessary and may cause harm to the subsequent use.
  28. Didn’t understand.
  29. Don’t be afraid to write your own bugs. Don’t be aggressive or secretive. Broadcast them, avoid others making the same mistakes at the same time, and adjust your mindset for the next time.
  30. The emergence of a new technology will certainly hype and exaggerate its performance, please remain vigilant, do not believe too much, read carefully, fully experiment before considering whether to adopt the new technology, avoid being a guinea pig.
  31. It’s important to keep abreast of new technology, read magazines and magazines, attend important meetings, and talk to people about powerpoint presentations that don’t seem to work.
  32. Don’t resist being asked to write a document by your boss or client. Be as demanding as possible.