Chapter 2. Avoid Whack-a-Mole Development
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 language 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[1] it. He names the variables and methods better. 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 alterations. When you take the new and improved functionality back to your customer, they try out the features that Rob implemented and are pleased with the changes.
Unfortunately, they discover something ...
Get 97 Things Every Project Manager Should Know now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
