Seven misunderstandings about entrepreneurial Programming

Over the years, there has been a general idea that software engineering should be the same as other types of engineering: careful design, accurate planning, and then development-strictly in accordance with the design specification. It's like building a bridge, isn't it? The problem with this development method is that software is "soft. It can be expanded infinitely. You can greatly modify your software whenever needed, and people do the same.

Also, because software can be used to model everything, the possibilities that software developers can implement are almost endless. Do you want to simulate an integrated circuit in the software? Do it. Want to manage a bank? No problem. Keep 0.5 billion people in touch with their friends? Why not? A piece of cake. Not only that, but we can also askProgramPersonnel perform various repairs and changes, which often appear in an unexpected form.

This is not like repairing a bridge.

Regardless of the ever-changing needs, countless projects have either failed or have been overbudgeted for many years. Therefore, in the face of evidence, why should the entire industry stick to this wrong understanding? It's hard to say why. However, in the end, the industry began to have a new understanding that software development should better respond to changes in demand. In fact, in order to adapt to such changes in demand, we should change to the software development process. There is no more entrepreneurial web development than todayCommunityThis trend is welcome. The so-called agile development methods have become popular. The "Lean start-up" campaign calls for automatic or experience-based rapid response to changes to running systems.

So we are all good, aren't we? Although the operation is not so fast. Although more and more agile development methods are accepted by people, there are still a large number of traditional misunderstandings wandering around us... Most of these understandings should be left behind.

1. Misunderstanding: You should recruit Japanese ninja programmers.

Superstitious about programming Superman is one of the most common diseases in Silicon Valley startups: A lonely programmer who develops a complex system overnight with pizza and coffee as energy and headsets, everything is done by yourself. The time has passed. Software development has evolved into a group movement. All start-ups will grow as long as they have achieved any meaningful success. If a single programmer is able to win the game, it will be impossible for a company of 10 people. What's worse, encouraging the heroic actions will lead to corrosive functional barriers in the development team. Consistently writing the solid functions of the company's survival from day to dayCodeThe programmer lost to a savvy and extreme self-interest who can work overtime overnight (usually only one night) to expect generous rewards. Rather than reward such a hero, it is better to cultivate truly team-oriented employees.

2. Misunderstanding: programmers need to work quietly to avoid disturbing themselves.

It sounds reasonable to let people work alone. Every interruption actually interrupts your thoughts, and it takes a long time for you to regain the "status ". Some famous software companies even insist on arranging independent offices for every programmer. They will not be disturbed in this way, will they? Unless modern new forms of interference don't get you distracted when a real person shoots your shoulder, such as instant chat tools, mobile phones, Facebook, Twitter, e-mails, and the music from the headset that programmers wear to help concentrate. The reality is that most programmers who work alone spend only a short time each day on real programming: various forms of interference are endless, all day long, they are going back and forth in the cycle of entering the status and losing the status. However, there is a way to solve this problem: Pair programming. Two programmers, one computer. No email, no Twitter, no mobile phone calls (at least no unplanned phone calls; you can handle such calls at regular intervals ). If you do this, you will get a fully programmed day. Besides, working with others makes the process of "going into the status" Almost time-consuming. This is a completely different way of working. I believe this method is much more efficient than working alone. In fact, I think this is the only way to maximize the efficiency of the software development team in view of the "distracting force caused by electronic devices" in the current office.

3. Misunderstanding: startup companies are fiercely competitive, so everyone should be exhausted.

Working overtime without a day or night does not allow you to do more and do more quickly. In fact, this will make you counterproductive. Yes, you think it will be done in a week. However, the development plans of most startups are longer than this. Programmers usually need to develop for several months (if not a few years) to successfully complete a product. The behavior of many startups seems to be like this pot of gold is put in that corner, as long as you can work harder to get it. Soon, the developer's energy was exhausted. For example, botnets only work overtime without any efficiency. High-intensity jobs only get more efficiency in the short term. Pivotal, a well-known Development Company, has helped hundreds of startups develop systems, and has always completed tasks in strict accordance with 40 working days.

4. Misunderstanding: A short schedule is required.

Many teams write poor code on the grounds of high market pressure and immediate product release. The written test program bypasses the problem location; the design principles are left behind in the crazy storm. However, as software development teams, everyone is the same. High-performance teams do not have to lose their hero qualities after success: on the contrary, when the pressure arises, they will not move, and successfully resolve the task with their own deep skills. We have heard countless stories of high achievements under high pressure-either military operations, professional sports, or pilots landing on the River-the reason is nothing more than the words of heroes, "We have been specially trained ".

5. Misunderstanding: developers should be solely responsible for their own code.

It sounds correct to be responsible for your own code. Of course. Personal responsibilities. However, assigning owners to the Code in the development team means that only one developer can write programs in each module, and only one person can master them. This leads to "local protectionism" among programmers in charge of the module ". For the company boss, this creates a great risk, because losing a person in the team will affect the progress of the entire team. If this person is responsible for the key core modules of the system, this will even paralyze the company's business. A healthy way of working is to let every programmer pass all the code in the system. Pair Programming allows you to achieve this effect, and knowledge will be transferred from one person to another. The so-called "Bus Index" is a key risk indicator for software startups. What we are talking about here is not only about the bad bus, but also your competitors. They are happy to dig your best programmer. The more people you understand the entire system, the more robust and dynamic your company will be.

6. Misunderstanding: You need a weird recruitment process.

Will you not perform an audition when you hire an actor? If you want to try it, you will be able to make a director for a short time. This is exactly the scenario where almost all companies are looking for programmers. Generally, interviews will talk about the applicant's experience. This is the end. You can imagine asking a man-filled actor whether he likes to play the role of hampir. Can you pass on the role of God? Okay. You have been hired! Many well-known software companies like to give their candidates a sharp turn. Some top companies even perform iqtest for candidates. The most desirable of them is to simulate Software Issues on the whiteboard and ask candidates to solve them. These situations are quite confusing. What I want to talk about is the obvious truth: the only reliable way to recruit good programmers is to program with them. My interview with programmers is an hour of fast pairing programming with them-and this is just the beginning of the interview. A large number of filters give them a full score of 100. What will be selected? Agile thinking, strong abstract thinking ability, master variousAlgorithm, Strong problem solving capability. The most important thing is understanding ability. Because collaboration is the most important thing for the team. If you don't understand how others think, it's useless to be smart.

7. Misunderstanding: professionalism is very important.

Naturally, managers are used to breaking down problems when they encounter problems. In the development team, this usually encourages the technical staff to develop specially. Front-end development, Background Development, and database administrators. Brad Feld suggested in his blog that every team should have an "all-around programmer" who is a real talent. He is right, but he is not talking enough. Every member of each team should be talented. Why? The team is vulnerable because of professionals. Do you still remember the "Bus Index? Every professional talent is a weakness. If he leaves, you cannot find someone to replace him. You're done. In addition, it can also make the team functional disorder. Special users need to communicate with each other's modules in their systems through defined interfaces. In fact, each of them wrote their own different communication methods. This leads to a large amount of extra spending, and often leads to "local protectionism" or mutual criticism. In the famous pivotal company, Every programmer has to access all aspects of the system, from HTML and JavaScript to Ruby to databases. However, some people think that professionals are more professional at a certain level of the system, which may not be able to stand up. Today's software technology has become less complex. Programmers can easily master the knowledge at all levels and how to operate on them. By the way, this implies another very important piece of information: you no longer need to recruit talent for a particular technology. Lack of Ruby programmers? Well, recruit a Java programmer and train him to use Ruby (this is especially effective for programming ). Some people call themselves "server-side" programmers? No problem. Let them write javascript programs and they will soon be able to learn.

If they are talents, they are here.

This article is from what's your start-up's "bus count "? 7 myths of entrepreneurship and ProgrammingArticleTranslated.