In the past 1 year, we have done many tasks and released many programs. I suppose you are not very satisfied with our job, for the problems when software delivery and release. In my opinion, the most serious matters are weak product, low productivity, executive ability, release delay and delay. We must do wrong things or do the wrong way or forget something.
I have made many suggestions, but for my poor English skill, I couldn't talk to you directly. Now I decide to improve my English and write articles in English to you.
For customers, the most important aspect of a product is quality. For us developers, the most important is the cost, consists of labor cost and time cost. So, our task is how to design and implement a nice product in a short time as possible. Let's analyze the developing process, first is the requirement, and then the design, next coding, next testing, releasing, maintaining. These are the common kinds of tasks we must do in a releasing plan. Problems come:
1. Document form. We developers get the requirements by Work Instructions. In this team, most of members could not understand the document very well without good English skills. So Adam will be the only channel, in other words, a bottleneck, accordingly, time will be wasted. My resolution for this is to separate the big document into small tasks, the small tasks are easier to understand, carry out and examine. In different period, there are different form and style for the requirements. When customers offer the purpose, it may be the work instruction. Before developing, we must separate that into small tasks, I defined a form of task, and you may alter or mend it into new different versions for different scenarios. Another point I want to say is, most of the time, the requirement is not a solid things, maybe it's better to implement code after defining the small task for a week, the delay time is for waiting for the requirement stabilization, and perhaps in this period the better design for it will come into the developer mind.
2. Code structure & style. In the past time, when a programmer wrote a suite of codes for a requirement firstly, these codes will become a model, everyone is asked to repeat alike code for all the alike requirements. Why to do so? One says, teamwork (when a people leave team, the other can maintain his code well, because the process is same), to complete task as soon as possible. It is right? I don't think so. However clever a programmer is, within the code he firstly write, there must be some mistakes or code or structure that can be improved better. If we repeat his code regardless, we are repeating wrong code (I don't mean we can't get the right result, but walk on the wrong way). To generate the accurate result is only the basic requirement. I wrote 2 articles named 《program is a girl》 and 《standards to estimate code》, the most important things are readability, modularization, flexibility, maintainability, and size of code. I've read many rubbish code that didn't abstract the requirement, didn't be separated into different modules, and even contains "goto". What's the reason we repeat it? If we do so, we give up the readability, modularization, flexibility, maintainability, and size of code, everything only except the right result. Next, let's talk about time. Is it true if we repeat a bad code, we'll complete the task fastest? In more times, I don't think so. The bad code commonly has big size, complicated structure (has no structure, or several unrelated code placed in one function), duplicate code. It is the alike function we will write, but not the same one, so we must alter the necessary code for a particular requirement. For complex, it's not easy, but mistake is easy to make. That means, though we completed the function quickly, when testing, a bug is found, but for duplicated code, the bug is in many places, who can assure that all the bug will be fixed at one time? If after a long time, one requirement changed, people (who write the complex code) forget the former process or a new people don't know the logic, they must read the code carefully, for the readability thrown away, they need long time. Long time, long time, everything needs long time, should we really complete the function quickly only for the right result? No, we need essential refactoring, improving, and specially, in our team, there must be an expert assigned to review code and push the team to perform the best practices.
3. Slow tools. Slow PC, slow network! God, we are professional programmer? From want of support, who know how much time we spent to waiting for the response of tools? Win7 will be setup this time, but network still need to improve.
4. Test way. Design & document is not taken into the testing process. Software is tested laxly, no document, no strict test case, all these produce the weak product. We should design the test cases, and write some automatic script, so that the bugs can be found as much as possible, and the speed of testing can be accelerated.
5. Attitude. I mean self-perspective. We have no the courage to research and face the past mistakes. We said too many good words to ourselves, such as we used XXX design pattern in XXX project. In my opinion, the detail code is more significant, because they are the main part of a project. In our projects, there are many big functions with too many code lines. Some code line is too long to read, line return should be added to separate it to several lines. HTML indent is not well performed. We repeat these wrong way again and again, no one desire to renew self better and better. Everyone only makes a program can run, not for excellent. We need define some better processes and mechanisms, and then perform them. There is a saying in China, sharpening your ax will not delay your job of cutting wood. We need spend more time on sharpening ax.
I'd like my life filled with thinking, passion, and creation, not the repeating.
