Programmers should cherish life and do useful and meaningful things. There are two ways to do useful things: one is to do a project that is really valuable to users, which is really meaningful and useful; the other is to do the project in the right direction and in the right way. But programmers will encounter a lot of failed projects. These systems are either not used and have no real value, or they do projects in an incorrect way and use improper technologies, such as using report tools instead of queries, using ESB enterprise bus as mass data transmission, or doing some functions that have no practical use, such as making a universal user-defined query system , do user-defined workflow tools, do user-defined report tools, these projects are undoubtedly a waste of programmer’s life. The author attempts to summarize several ways that programmers waste their lives, as follows.
1. Developing a system with poor quality and performance
Programmers often encounter such projects, the quality of the system is very poor, no feedback operation, no prompt failure, and the speed is very slow, operation from time to time to wait for a while. However, the key is that programmers do not have the opportunity or do not want to participate in the implementation and maintenance, and lose the opportunity to learn and diagnose problems.
2. Spend a lot of human and financial resources to develop a one-time project
This is often encountered by programmers engaged in application development. To develop a one-time customized project for a certain customer, however, this project will cost a huge human cost. The final development and maintenance cycle is very long, and it will end at a huge loss or can not end.
3. Develop a very beautiful and fancy unmanned system
This is also a common situation at present. Customers need to do a highlight project, a system with beautiful and fancy interface, all kinds of charts, all kinds of interaction methods, all kinds of monitoring and analysis, but in the end, no one will use such a system. It’s just for leaders or guests to visit.
4. New development of a legacy system
The leader of the programmer should make a new product based on the original system, greatly improve the maintainability and scalability, increase the stability of the system, and reduce the system failure. The leader decided to call the team together to conduct requirements research, requirements analysis, architecture design, coding development and testing again. However, this kind of thing is repeated again and again. The same similar requirements have made new systems for different customers, and the failure and instability of each system will remain after a period of time. Various versions and code bases are left to programmers… Programmers need to maintain different versions of the system for different customers.
5. Developing a system with uncertain project scope
There is no one to manage the scope of the project, no WBS, no contract or contractual constraint from the user. The user has to do more and more, and the system is becoming bigger and bigger. Finally, it can’t be controlled. The customer is not satisfied, and the programmer is tired to death. The plan of trying to please the customer and strive for a larger project fails.
6. Develop a system without system roles or stakeholders
Although this project has requirements, functions and interfaces, it is strange that the requirements are not mentioned and no one knows who uses these functions. Requirements do not define the role of the system and the business activities that the role will participate in. However, such projects are not uncommon,
7. Develop a project with uncertain usage environment
The enterprise application project made by the programmer does not know whether it is for the computer or the mobile device, whether it is for IE or other browsers, whether it is for IE6 or ie10, and the browser platform version cannot be determined. Mobile devices don’t know whether it’s IOS or Android, Android doesn’t know whether it’s 2.3 or 4.0, and it can’t determine the model of mobile phone or tablet. We know that medium-sized enterprise applications are much more complex than Internet applications. It is almost impossible to cover all users’ terminal platforms. To be an excellent system, there must be constraints and target platforms.
In view of the above situations, programmers often have no way to intervene, because it is either the behavior of the customer knowingly, or the strategic behavior of the company department, or the lack of basic skills and responsibilities of the project manager. Of course, programmers can assume that they are project managers, consider how to do these projects well, and put forward problems or solutions timely and appropriately, so as not to waste their lives.