50 years of experience in software development to bring my 63 revelation

Technosphere can practitioners 50 years of developer is precious, author Karl Wiegers is the software industry practitioners with such a rich experience in the past 50 years, he has accumulated 63 revelation, share and sort out , I hope for your inspiration.

Author | Karl Wiegers, translator | Champagne Supernova

Zebian | TANG lead

Head Figure | CSDN download from Eastern IC

Exhibition | CSDN (ID: CSDNnews)

The following is the translation:

In 1970, I was in college on the first church programming class ( of course, a student of FORTRAN ). In the past half century, a lot of my time is spent working in the software: requirements, design, user experience, programming, testing, project management, writing documentation, leading process improvement, writing seven books and many articles, consulting, training.

Of course, in the process also completed a number of side quests, such as reading the organic chemistry PhD ( my paper one-third of all computer code ), for a few years researchers. But basically, I'm a software industry people.

In such a long period of time, I accumulated a lot of opinions about the software industry. In this article, I will share with you 63 revelation, perhaps you would like me to find them useful.

About Demand

1. If you do not thoroughly understand the needs, then the rest of the items you no matter how useless, will eventually fail.

2. After lunch you find at the desk paper notes, preserved voice mail and e-mail, and remember that casual conversation on plausible corridors, all of which can not be regarded as a demand. It's just a bunch of information only.

3. For all project stakeholders, the intersection of interests in the process requirements (Requirements Process) occurs the most.

4. If the lack of demand for high quality, content stakeholders who might feel more unexpected was the last delivery. In software, the accident is almost always synonymous with bad news .

5. In exploring needs, please do not just consider the current user. Have you ever customer is still your customers.

6. People should not just go to "collect" demand. Demand is exploring acquisition, collaboration, discovery and invention, rather than just a simple collection. A business analyst not only to dry live scribe.

7. The purpose is to obtain demand voice of the customer - that is VOC, voice of the customer-- close to the ear developers as much as possible - that is EOD, ear of the developer. Business analysts can help bridge the communication gap between them.

8. For requirements elicitation, people often hope in two ways: "telepathy" and "clairvoyance." But different from useless.

9. No matter what our culture claims, but in fact the customer is not always right. But the customer always has his own opinion, but you must understand and respect this opinion.

10. iterative development needs demand. You can not expect the first discussion to get to all the requirements; to know that you may never be able to completely get to. Effective demand development involves the gradual improvement of detail and clarity.

11. Do not be afraid to demand recorded. Compared with the cost of access to knowledge, knowledge of low cost records.

12. If some functionality or features not described in the claims, it is no one expects to see in the product.

13. The demand for the development of deliverables is not just a set of written demand, but a consensus and consistent expectations.

14. The need for development in terms of, how perfect more realistic goal is not to create the demand, but the demand is sufficient to create a team at an acceptable risk level for construction. The risk is that, due to neglect, unnecessary, incomplete, ambiguous or output in case of poor communication needs, and the case had to rework the plan outside too much.

15. We sometimes more casual in the expression of demand, because we can assume that the reader has a similar with our own "rational filter", but for the same period of the statement, it is often interpreted in different ways. This ambiguity can lead to unexpected and matched expectations upon delivery.

16. The audit team needs to keep the studio and on a smaller scale. A large group of people the same even if you want to leave a room on fire can not do the views, not to mention the agreement in an on demand should be worded.

17. When someone proposed new requirements, the first question to ask is: "? We do this within the scope of the discussion ," If it is, it must be addressed. If not, it would not solve, or at least not now be resolved. However, if the answer is "No, but we should be concerned about this issue," then you have to adjust the range to accommodate it. This, schedule, resources, participation, priority and cost-effective compromise have an effect.

18. If you do not have a documented and has been agreed project scope, how can you know if you are experiencing scope creep?

19. In deciding what features to include in a product or iteration, avoid "decibel priority" approach (commonly known as allocation by downtown). Loudest customers who functions required from a business point of view, not necessarily the most important.

20. The project stakeholders must be able to understand the needs of potential discussions with the commitment to include it among the product is different.

21. There are two terms, must be vigilant when you hear: "assuming that demand" and "implied needs." To strive to clearly communicate expected demand.

About Project Management

22. "Project Management" does not refer to a specific activity. Project management is people management, demand management, risk management, opportunity management, expectant management, commitment to a mixture of management, change management, resource management, and supplier management.

23. Why do some companies never have time to It well the software, and the subsequent always find time, money and manpower to make up? This is a mystery.

24. Everyone is willing to believe their team has the top talent, but the fact is that half of the capacity of all software developers are below average. Well, these people are working where?

25. Do not evaluate anyone. If others ask you to assess the most appropriate response is: "Let me think about it first, and then go back with you now."

26. No matter how much pressure you applied to others, do not give any promises they can not keep.

27. If you do have compelling data, while the other hardly any data, you will occupy a dominant position in the negotiations.

28. Unless you record and assess what actually happened with the comparison, otherwise you will always be guessing, rather than in the assessment.

29. not because I think the other side like to listen to good words, it affects your assessment of someone.

On quality and process improvement

30. With regard to software quality: You can pay me now, you can pay me later, but to pay more.

31. strive for perfection; pursuit of excellence.

32. Do not always be a bad thing to do to convince the boss or client.

33. Quality should be your top priority. The result is high-quality natural productivity by leaps and bounds, because this team does not need to waste too much time to rework.

34. strive to make a peer, rather than customers to find defects. Peer review technique is an effective technology that can improve quality and productivity.

35. If the person you are dealing with is not unreasonable, and that any software engineering techniques useless.

36. When people were asked to change their way of working, their instinctive reaction is to ask, "What's in it for me?" But in fact, this question is asked is wrong. Proper law should be asked, "What's good for our team?"

37. Software developers are always looking for excellent tool, but remember, after little fool have the tools will only dull boy.

38. When the point where people do not understand the pain caused by the current work in, for process change is very difficult. Like if people do not know their own home with a mouse, it is difficult to sell them better mousetrap.

39. Q: How many light bulbs to replace the software process owners need? A: Only one, but only if the bulb must be willing to be replaced.

40. In the process of working towards a new way of development, do not underestimate the degree of difficulty and the necessity to change the organizational culture. The implementation of a new process to a new culture faster than indoctrination. You do need to have success on both fronts.

41. Regardless of whether it is well-intentioned, if not improvement plan into action that to no avail.

42. In many cases, common sense, good judgment and the experience should be more important than formal procedures. Sometimes, however, the existence of this program is fully justified. Before deciding to bypass the need to look into it.

43. In leading organizations to adopt new ways of working, please continue gently applying pressure.

44. The best power can contribute to changing the way work is painful. Not artificial, externally applied painful, but work to bring a team of very real pain of the current. Select those that can ultimately alleviate the suffering of activities to improve it.

45. Unless you take the time to review and learn lessons and continue to improve the team's process, otherwise there is no reason to expect the next item can do better than on a project.

46. You can not look to change everything. Identify those process changes can bring the greatest benefits, and next Monday began. I'm not kidding: that is next Monday!

47. The use of "shrink to fit the" concept document template. Start with a rich template to start, to give more consideration to remind you what information may be contained in, and then to reshape according to the size, nature and needs of each project.

48. There are many teams are required to do more with less. However, under normal circumstances, they did not make their own method multiplier. If there is no appropriate training and process improvement to increase efficiency and effectiveness, do not expect higher productivity will be fabulous to reveal itself.

49. suitable for four people working in the same office is not extended to informal processes in multiple development teams working on different continents above.

50. If the software industry, there is nothing that can be reproducible, it is repeatedly doing the same stupid things on one after another of the project. You need to learn by reviewing, understanding, and continuous improvement.

51. When people do not follow established procedures, before you have only three choices: (1) so that people began to follow the process; (2) the adjustment process to make it more effective and practical, and then let people follow it; (3) give up this process and not to pretend that you follow this procedure.

Other opinion

52. AI can not replace the real thing.

53. In the technology sector, if you lead other people for a week, then you're a big brother.

54. Today's "must fix it immediately," the kind of development projects will become tomorrow's legacy system maintenance nightmare.

Software and software, software, and hardware, software and people, and people: many of the problems 55. software systems have occurred on the interface. These interfaces need a good study.

56. People always too much to talk about their "rights." While the other side is the responsibility of each of the rights. To collaborate with the mentality to think and act.

57. An ounce of design equivalent of a pound of reconstruction.

58. Beware of "Business Week-style management" - Just because someone read the excellent results it promised, we rush to adopt the hottest new thing in software development.

59. maintaining an inch distance between the thumb and forefinger. In most cases, this is the only difference between quality and junk. Just listen to a little more than that, check your work, run the test again, reference list, read the instructions, raise another question. Typically, this is the only way to improve waste.

60. You do not have time to re-commit those mistakes again committed before the software practitioners. Read and respect for literature. Learn from your colleagues. Generously share your knowledge with others.

61. The software development computing technology may account for 50%, and the remaining 50% is to communicate. But business analysis is entirely in the exchange of communication. We have to account for more computationally.

62. If you want to live on their own to be an independent contractor or consultant, you'll need to declare himself available to the world. If no one knows you, no matter how good your business capabilities useless.

63. In the software industry, we often pretend. We pretend to have found the right stakeholders who understand their business goals and know their needs. We pretend we have the right people to convey the right requirements, and we do understand and accurately recorded. We pretend that our assessment is accurate, and we have taken into account all the necessary tasks. We pretend all possible risk would be damaging to our project are not really appear. I do not pretend to love. Sometimes, I do not like so much reality, but my reality in addition to nothing, so I have to face it. Let's stop pretending now.

英文：63 Lessons from 50 Years of Software Experience

Original: https: //medium.com/swlh/62-lessons-from-50-years-of-software-experience-2db0f400f706

About the author: Karl Wiegers, writer, writing covering software development and management, consulting, self-improvement, chemical, military history and other fields, he is still writing a suspense novel.

Translator: Champagne Supernova

This article CSDN translation, please indicate the source of the source.

【End】