The Way to Neat Code - Reading Notes (10)

The Way to Neat Code

Synopsis:

This book is a summary of the experience of programming guru "Uncle Bob" over 40 years of programming career, explaining what kind of attitude, what kind of principles and what kind of actions are needed to become a real professional programmer. The author takes the detours and mistakes he and his colleagues have made as examples, with the intention of guiding those who come after him and helping them to take a higher step in their careers.

This book is suitable for all programmers and can be used as a reference for all those who want to become professionally literate in the workplace.

Chapter X. Estimates

Forecasting is one of the easiest and scariest activities software developers face. Estimation affects huge business value, is a matter of reputation, and causes a lot of anguish and frustration. Estimation is the main obstacle between business people and developers, and it is almost always the cause of all the mistrust that exists between them.

10.1 What is a prognosis

Different people have different views on prognostication.The business side feels that a prediction is a promise. Developers think estimates are guesses. The two are very different.

Commitment:

Now that you've made a promise, you must honor it.A promise is something that must be done. If you promise to make something happen on a certain day, you have to do it on time. Even if it means you have to work 12 hours a day and give up weekends off, it has to be done.

Commitment is about certainty. Others will take your promises seriously and draw up plans accordingly.If they can't keep their promises, their losses, and the impact on your reputation, are huge. Promises that can't be kept are also a form of deception, just better than blatant deception.

10.2 Estimate:

A prognosis is a guess. It contains no overtone of commitment. It does not need to make any promises.

The prediction is not a fixed number; the outcome of the prediction is a probability distribution.

Professional developers are able to clearly distinguish between estimates and promises. They will only give promises if they know exactly what can be accomplished. In addition, they are careful to avoid giving implied promises. They will state the probability distribution of the estimate as clearly as possible so that the supervisor can make appropriate plans.

PERT:

Part of PERT is a method of calculating the prognosis. This technique incorporates a very simple but effective way to turn the prognosis into a probability distribution that is readable by supervisors.

By estimating the project development progress from three different perspectives, i.e., optimistic, nominal, and pessimistic. Then find its expected value.

10.3 Estimated tasks:

At the time of the prognosis, the most important resource is theYou're surrounded by people.They can see what you can't. They can help you anticipate tasks more accurately than if you were to go it alone.

The Durfel Act:

The approach is very simple. A group gathers, discusses a task, estimates the time to complete it, and then repeats the "discussion-estimation" process until there is a consensus.

Specific operations:

1. show off one's finger

   Everyone sits around the table. One task at a time is discussed. For each task, it is important to discuss what the task involves, what factors would complicate it, and how it should be accomplished. Then all participants bury their hands under the table and hold out 0 to 5 fingers, depending on their judgment. At this point, the facilitator counts 1-2-3 and everyone shows their hands. If everyone has the same number of fingers outstretched, the discussion of the next task begins. Otherwise, start discussing why there is disagreement. This is repeated until there is a unity of opinion.

2. Planning Poker

   Planning poker is very simple to play. Cards of different points are dealt to each member involved in the prediction. If the number of cards dealt to each person is between 0 and 5, then logically, it is a game of Bright Fingers. Pick a task to discuss. At some point, the facilitator asks each person to play a card. Team members pick a card based on their prediction, with the back facing outward, making sure that no one else can see the card's points. The facilitator then asks each person to show their card. The rest is the same as showing fingers. If there is consensus, the prediction is recognized. Otherwise the cards are taken back and the discussion of the task continues.

3. Estimates of association

   In Associative Pre-estimation, all tasks are written on cards that contain no information about the pre-estimation. Have the people involved in the prognosis stand in a circle at a table or by a wall and spread the cards out in a disorganized manner. Everyone remains silent, except that the cards are sorted according to how long the task will take, with those that take longer on the right and those that are shorter on the left. Anyone, at any time, can move any card without caring if anyone has moved it before. If any card has been moved more than η times, it needs to be pulled out and discussed individually. Eventually, the silent sorting terminates. A discussion is begun to detail where the sorting opinions diverge, or a short design discussion or hand-drawn wireframe sketch can help achieve consensus.

4. Ternary Estimates

   The Delphi method is a good way to go if making nominal predictions for individual tasks. But as I said before, in most cases you need to make 3 predictions to get a probability distribution. Regardless of which form of the Delphi method is used, it is possible to quickly get optimistic and pessimistic predictions for each task. For example, if you choose to use planning poker, you can ask people to show their cards based on the pessimistic estimate and then choose the one with the largest number of points. The optimistic estimate would be the same, except that the one with the smallest number of points would be selected.

10.4 Theorem of large numbers

Estimates are very prone to error, that's why they are called estimates. One way to control errors is to use the law of large numbers. What the law means is that dividing a large task into many small tasks, estimating them separately and then adding them up will result in a much more accurate result than if the large tasks were evaluated individually. The reason this improves accuracy is that errors in the estimation of small tasks are almost negligible and do not significantly affect the total result.

Frankly, that's rather optimistic thinking too. Mistakes in estimates are usually underestimated rather than overestimated, so splitting and then totaling is hardly perfect. Still, splitting large tasks into smaller ones to estimate them separately is a good idea. Some errors will be overlooked, and splitting into smaller tasks makes it easier to understand the task itself and other unexpected factors.

10.5 Conclusion

• Professional developers know how to provide business people with credible predictions of results in order to make plans. If it can't be done, or if you're not sure it can be done, a professional developer won't give a promise.
• Once professional developers make a promise, they provide firm numbers to deliver on time. But most of the time, they don't make such promises and instead provide probabilistic estimates to describe the desired completion time and possible variables.
• For prognostic results that need to be treated appropriately, the professional developer consults with the rest of the team to reach a consensus.