For software project managers, the need to deliver products as early as possible, their pressure is often huge, then, in the face of great pressure, project managers how to do Super speed, to complete the task, the following is a suggestion.
Suppose your team has two programmers, Bernie and Rob. Both are very competent, the same knowledge, programming language skills are equivalent. You've found that in the development process, Bern has been implementing software functions much faster than Rob.
When Bernie was focused on fast programming, Rob was spending time writing code and refactoring ①. Rob is better at naming variables and methods. Once the written program was able to run, he divided the program into small pieces. Now he has to write tests to make sure that every piece of the program works as he intended. When he felt the results were more satisfactory, he declared that he had achieved the function.
But suppose you don't know these details. If you just look at them and who claims to be functional, then obviously Bernie is doing better, right?
After a few weeks, you demonstrate these features to your customers. As always, customers like what you've done, but now you need to make some changes and improvements. You let software developers modify the code. When you bring the new features back to the customer, they try out the functionality that Rob has achieved and are satisfied with the changes he made.
Unfortunately, they found Bernie's functionality somewhat odd. When Bernie writes new features, some of the previously available features are now unavailable. The customer marks these as flaws and then you let Bernie make the changes. Once again, the customer tests these features, and the resulting new features are not available. What the hell is going on here?
If you have children, you will know what happened. Bernie created a Gopher-style application. Playing the hamster is a game, the children with a stick to beat a few holes in the random pop-up of the hamster, they will be surprised to what the next mouse to play out, but also enjoy. However, when you modify an application, it is not a fun thing to have bad code popping up from somewhere. That would be frustrating and unpredictable, and it would slow down the pace of product development. Bernie began to sprint at full speed, only to the opposite.
Although Rob was slow from the start, he actually wrote more code than he did. It turns out that his rhythm is sustainable. Since the original code has a good quality, he can make possible changes faster. And the tests he wrote earlier could give him feedback at any time, letting him know if his new code was compatible with the rest of the original application.
When estimating the implementation time for a feature, do not only take into account the time it takes to write the code initially, but also the time it takes to upgrade, adjust, and improve the code. Writing high quality code and testing takes time. In the short run, it seems like a loss, but it's a long-term gain.
Ask yourself whether you want speed or the enjoyment of sustainable development.
① refactoring is to change the code, improve its internal structure without changing its external function. It improves software PRODUCT design. Refactoring code is to go back to perfecting an available feature that was hastily created and tested. There is now a need for further internal improvements to the functionality for long-term use, and to make it more convenient to add functionality later.