Why we should avoid rework?
Have you ever think about the rework you realize every week? Do you know how much time have you spend doing rework during all your working life? According to Nussbaum in [1], an average software development team reworks 26% of the code they wrote. If we think in the case of Costa Rica, where the labor journeys are of 40 hours a week, that’s about 10.4 hours per each team member, which means more than 1 labor day…
The biggest question here is why we don’t do things in the right way the first time? Many of us could think that when we start a new task, we don’t know exactly what the customer wants, even if we follow all the acceptance criteria from the board, the customers always wants changes! But that is no an excuse to do reworking, because we can avoid that if we do a deep analysis of the customer needs before we start writing a single line of code.
Many times we think that some tasks are very simple, so we feel good with the acceptance criteria and we follow every single instruction there, so we finish the task in the estimated time and we deliver it. But then the customer told us that he needs a single column more right-sided, so we change it and we deliver the task again. Then the customer ask to add a new column that shows the update date time of the rows, so we take the task, add the column and deliver again. This time, the customer accepts it and merge it to develop and staging. But if we analyze what happened here, we come up that this is pure rework and we should ask, why I don’t place the column more to the right and add the update date time at the beginning? Of course we don’t know that the customer will want to do these changes, but also we never ask if what we were doing was ok during the programming process so we realize that when we already finish the task, do the tests and create the PR, the customer will ask for visual changes, something that could be avoided.
And I’m not telling that we can’t do rework, because I think that is something that will be present in every project in every single sprint, but I think we can reduce that 26% of the code (which is actually time) reworked if we maintain a better communication with the customer, product owner, product manager or whoever is the one that creates the tasks for the current sprint.
Also there are the cases where we start doing a task but we don’t know very well the technology, so we try to do our best and we use methods and helpers that we consider are ok for what we are doing, so we test everything and if it works, we create the PR, thinking that we do an excellent job because everything that we do works fine. But then our tech leader rejects our work and ask for changes, telling that those helpers methods and queries used, makes the program very inefficient in terms of time.
Both of those situations are things that can be avoided when we are working. First, I think we have to maintain a very good communication with the customer, asking for what they want exactly and showing them what we are doing so we can get feedback and do the necessary changes before finish the task NOT after, remember that most of the projects use agile methodologies, so we can show our work in the daily stand up. And second, if we are not sure with what we are doing, we can ask for help to a senior developer, I’m pretty sure they will help you, not just to get the task completed faster, but to make it efficient, easy to understand, and make the code more scalable, which will reduce the time spend when a new feature needs to be added in the future. So in conclusion, my recommendation is to always ask for feedback and help, and I’m sure that here in Pernix you will get that very easy, which will help you improve your soft skills, your technical knowledge and become a better professional faster than you expect!
References
[1] Nussbaum, H. (n.d.). Rework is Costing Your Company Millions — It’s Time to Cut Back. Retrieved from: https://codeclimate.com/blog/rework-costs-millions/
