Rewriting a feature can bring both challenges and opportunities: the challenge of ensuring all functionalities continue to work and the opportunity to use the past learnings to improve the implementation.
Recently I’ve been working on rewriting a feature from an internal library my team owns. The feature was developed some years ago and over time, it has required extensions, changes due to product requirements, and bug fixes as usual. Originally it was used in one single place and now we need to use it in other products, making us realise the need for more flexibility and less coupling. The main reason we’re rewriting is to support new sub-features and improve the overall experience. This is part of the initiative I mentioned in my previous post and I’ll write about it when it finishes.
Pairing in Software Development sometimes is underestimated due the time investment that it needs. Sometimes we also want to do some code alone, because pairing can also be exhausting. But the return we have from pairing is something that should be considered.
Rewriting this feature is a perfect case for pairing, while one has some context about the new library to be used and can share about how to use it. During the process the pair can have discussions about the usage of the library, try out new approaches when facing challenges and use the learnings from the actual feature.
It’s not just about getting the work done - well, in way it should be because it needs to be finished right? 😅 - as now we have the perfect opportunity for some improvements.
Improving code should be part of a developer's responsibilities, and sometimes we need to find the correct time for doing so. Even some well-intentioned spontaneously improvements can cause some problems. I believe it’s better when we discuss as a team, proposing improvements and getting feedback from them via pairing, code reviews, team dev huddles. While we should own our code, we should remember that isn't only ours. We own in a way that we’re responsible for it, we should maintain, ensure quality, readability, fix it. Not in a way that “it’s my thing and no one can touch it”. Especially working in a team.
During this process we’re discussing a lot of ways we think could be better implemented, trying to understand the reason behind what we had done in some way before to properly plan the new way to avoid some issues we already faced.
Not blaming anyone, I don’t like to see “who had done it”, it could be also me for sure. Something that really guides my work and some parts of my life - and I really mean that - is the 'Prime Directive' from retrospectives:
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” - Norm Kerth, Project Retrospectives: A Handbook for Team Review
As we’re rebuilding this feature we’re having good discussions to create it more robust and configurable. Soon we will also share with the rest of the team, there is still some more work to do.
And maybe some Software Engineer from the future can see that it could have done better and it’s okay too. Continuous Improvement it’s part (it should be) of a Software Engineer’s life.
If you're still here. Thanks for reading :)