28 Principle: 28 Principles in software development

In front of the "what is the 28 principle", then we have to say how to use it. As this blog mainly talk about it technology, it is obvious to first say and the programmer about those things. In order not to be too abstract, we take the development of a text editor as an example (this thing everyone familiar, save the drool explanation), to say that different responsibilities of developers in the development process how to use the 28 principle.

Demand analysis

Demand analysis takes a small amount of effort throughout the development process, but has a huge impact (this is another example of a 28 principle). Since demand analysis is so important, it is supposed that the strongest people should be arranged. But this is often not the case: many companies responsible for demand analysis are not qualified for the job. I have experienced several projects that are not very successful, and the root causes of the problems are related to demand analysis.

The most important thing about demand analysis is: Figuring out what users really want? If the problem is wrong, biased, the next steps to do a good job is useless (for example, customers want a text editor, the result you have a graphical editor to him). In fact, there are a lot of ways in this respect, which is confined to the space, and if you are interested, you can talk about it in a separate way.

After figuring out "what the user wants", we'll sort out the list of features (also called Feature List) and filter out about 20% of the key features. This step is the main one I would like to introduce today, because this step is closely related to the subsequent development. In general, functional screening is based on the following:

1. Features that users often use (such as Save, copy, cut, paste)
2. Promotion of the selling point (to be able to exceed similar software, attracting eyeballs)
3. Functions that are closely related to the user's interests (this feature does not allow for errors, such as saving)

This screening process should be completed as soon as possible, and preferably by the product personnel, developers, testers, the head of the three parties to discuss together to ensure that the position is objective, comprehensive perspective. After filtering out the important function points, the other personnel's work arrangement should "take the key function as the outline", has the emphasis.

Project Management

If you are a project manager, you will have to prioritize the development/testing of key functions as much as possible in the scheduling of project plans, and arrange for the ability to do so. In my previous practice, the focus function plan had to make at least 1/3 of the time allowance, just in case (it turns out that almost every item that is slightly bigger will appear in the event of an eventuality). As for the non-focus function, try to get to the back and arrange for the ability of the general people to develop/test.

Then, in the course of the project, there must be regular meetings. As a project manager, you should focus on the progress of key features and risk situations.

Once the project has the risk of extension, it starts with the non-focus function (commonly known as chopping function). Due to the reduction of non-priority functions, it does not have a fatal impact.

Design interface

When designing the interface, you have to make sure that all common functions are prominently located (such as toolbars), and that they are easy to use (such as providing shortcut keys and right-click menu support).

For the selling point, it is not necessarily a common function, its purpose is to arouse the user's desire to buy and use. So you have to design them to be cool and gimmicks.

For the benefit-related functions, most of the cases are focused on the business logic implementation. If it is neither a common function nor a selling point, then the interface design does not necessarily have to be extra hard.

Other non-focused functions, as long as they are designed according to conventional methods, do not take too much effort.

Writing code

I find that many developers have a few common problems: to do fun or easy functions first, then do boring or cumbersome functions, to their own interest in the function of more energy, not interested in the simple response.

These are the major taboos of development. As a professional developer, you should not use your interests and preferences to determine the development priorities. The correct approach should be as follows:

You first have to focus on the key features described above, and make sure that their code quality is as good as possible, and that it is as easy to maintain (the key features are often changed and often modified).

For the "common functions" in the focus function, ensure that the timing is good (can be quickly responded to). For "User benefit-related features", ensure that bugs are as small as possible (especially for security, stability, robustness).

As for other non-focused functions, as long as there is no obvious bug, a small defect is harmless.

Test

If you're a tester, you'll also have to focus on testing those key features. For "user benefit-related functions", perform some tests such as robustness testing, stability, security, etc. (such as whether the test saves large files would be wrong). For common functions, usability and performance testing (such as copying and pasting are easy to use) is primarily performed.

For other functions, just perform a normal test to ensure that it does not appear obvious or serious bugs. You know, when Windows 2000 was released, thousands of unsolved bugs (all of which were low-priority) were left behind, and Microsoft did not publish as well.

Product Demos

Some software after the development, will engage in some demo to promote. If you are the person responsible for the demo, you must be the main demo time used to show the software selling point, so that the impression of the most profound, the best effect, as for the non-selling features, not necessarily mentioned.

Several and development related work is introduced here, finally gave the guys a word: do not working hard, working smart!

Next post is going to talk about the application of the 28 principle in management.

28 Principle: 28 Principles in software development