Here’s a question that came across the transom … it had to do with “… a 2-week Sprint where we went through a massive code refactoring in one of the major modules “ one of the quality engineers was wondering if the development team was being ineffective/inefficient …
The Question from reddit user
- We are working in a 2-week Sprint where we went through a massive code refactoring in one of the major modules (a web module); the developers’ (5 of them) justifications were:
- At the time of the development, they didn’t know how to develop it
- To make the codes better for future development
- After testing was completed, and suffice to say, was grueling as the tester had to go through multiple Sprints tickets and test cases just to re-test all the refactored codes, one of the developers took a ticket from the backlog where it also enhanced another “sub-part” of the module; therefore the tester now needed to re-test 30-50% from the same module again, and the test had to be done within the same Sprint.
Unsurprising, the tester asked, “if this is the case why wasn’t that “improvement” done on the prior work since the work itself is very close to the already completed work? The developer said it will not be as difficult as the prior one, which seemed to be an attempt to appease the tester, but the tester was not having any of it and complained to the test manager that the development process is being ineffective and inefficient in their development work, wasting testing time. - To the experienced QAs, what do you think of this situation? Is the development team being ineffective and inefficient? Was the tester right in concluding as such? What went wrong?
My response:
- The question posed (constant code refactoring) and the scenario presented looked like two different things. So, first step is to validate that we were dealing with a chronic – rather than an acute – problem.
- If the “massive code refactoring” was needed – and both rationales presented appear to be adequate reason for re-factoring – then there should be little argument about doing it. That doesn’t make the refactoring “constant” unless it recurs sprint-after-sprint-after-sprint …
- If there is constant refactoring then there is a serious project management/engineering breakdown. The quality problem in such a case is far removed from testing because the is a systemic process problem leads to a lack of stability in the product.
- In the case where there is a single “massive re-factoring” (not constant) then … having left major issues lying around in the backlog and/or allowing major issues to be picked up late in the sprint … that is a different project/engineering management issue. It suggests that the estimates of the effort required may have been be seriously flawed.
What does it take – what does it cost – to write one line of code? What do you include in the “what does it take” – documentation (user and developer), what quality assurance activities are needed, what tools or environments are needed, etc.
In our consulting practice, we have seen projects running with no estimates whatsoever. And no process for improving estimates, if there were any. How do you know how many user stories can be developed or issues resolved in a sprint if you have no idea of what it will take?
Estimation of the complexity of software work is notoriously difficult. New, green field development, often has so many unknowns that it seems impossible to estimate. My very first comp sci instructor’s rule of thumb seems to work:
- Take your first impression (guess) of the time it will take.
- Multiply it by 2 (or 102)
- Increase the units by 1 order of magnitude
- So … an original estimate of 4 hours becomes … 8 days
It is appropriate for a manager (or customer) to ask: what will it take (cost, effort) to get something done? How long – wall clock time – will it take? If you cannot answer those questions then it doesn’t matter how “agile” your process might be … you should not proceed.