Avoid Whack-a- Mole Development

朴灿烈づ我的快乐病毒、 2022-08-05 08:44 176阅读 0赞

## Avoid Whack-a- Mole Development ##

Venkat Subramaniam Broomfield, Colorado, U.S.

SoFTWARE PRojECT MAnAgERS face a lot of pressure to deliver fast. Time is of the essence. How can you get things done fast?  
Imagine you have two programmers on your team, Bernie and Rob. Both are capable, have the same amount of domain knowledge, and have equal lan- guage skills. During development, you find that Bernie finishes his feature implementations much faster than Rob.  
While Bernie focuses on getting the code completed quickly, Rob spends time writing code and then refactoring\* it. He names the variables and methods bet- ter. Once he gets things working, he breaks the code into smaller pieces. Now he writes tests to make sure each piece of his code does what he meant it to do. When he’s reasonably satisfied, he declares the coding of that functionality done.  
But assume you don’t know these details. If you only look at the speed with which the functionalities are declared done, clearly Bernie is the better man, right?  
A few weeks go by, and you demonstrate the features to your customer. As usual, the customer loves your completed features, but now wants you to change and improve them. You ask your developers to make those code altera- tions. When you take the new and improved functionality back to your cus- tomer, they try out the features that Rob implemented and are pleased with the changes.  
\* Refactoring: Reworking the body of code to improve its internal structure without changing its external function. It improves the software design. Refactoring code is going back to improve a working feature that was created quickly and tested. Now it needs further internal refinement to facilitate its long term use and make it easier to add future changes.  
  
Unfortunately, they discover something odd with the features that Bernie imple- mented. While Bernie has programmed in the new functions fine, now a few things that worked before don’t work anymore. The customer marks these as defects, and you ask Bernie to fix them. The customer tests the features again. Now even newer, stranger things seem to be broken. What’s going on here?  
If you have a child, you know what is happening. Bernie has created a Whack- A-Mole application. Whack-A-Mole is a toy. Kids are given a wooden ham- mer to strike moles that pop up at random. It’s fun for them to be surprised by which mole pops up next. However, fixing applications with broken code popping up at random places is not fun. It is frustrating, unpredictable, and it slows your product development. Bernie was sprinting initially, but he was running in the wrong direction.  
While Rob appeared slower at the outset, he was actually creating superior code. His pace proved sustainable. The better quality of his initial code helped him make workable changes quickly. Plus, the tests he wrote in the beginning gave him instant feedback regarding whether or not his new code was compat- ible with other parts of the application where the code was used.  
When measuring time for a feature implementation, do not consider only the time it takes to write it in the first place. Add the time it takes to enhance, fix, and improve the code. Writing good quality code and tests takes time. It appears to be a short-term loss. However, it comes with a long-term gain.  
Ask yourself if you want speed, or if you want to savor sustainable progress.