Refactoring can help keep a mature codebase fresh. But refactoring can impose a hidden cost when you support multiple releases.

A security patch or feature that you want to cherry-pick to previous releases will not apply cleanly post-refactor. More significantly, your engineers must remember the old design as well as understand the new, to synthesize a patch that makes sense for the older branch.

This is not an argument against refactoring! But keep this hidden cost in mind the next time you hack an old codebase.

• #FridayDevAdvice

If you are an introvert (as I am), remember to slightly overcommunicate in your daily emails and chats. What you perceive to be overcommunication is probably closer to the appropriate level expected by others in your team.

• #FridayDevAdvice

Keep your commits clean. Address only ONE issue per commit. Make sure the project continues to build and run at each commit. Your future cherry-picking or reverting self will appreciate it.

PS: And no sneaking in small, unrelated changes to avoid a code review! You know who you are.

• #FridayDevAdvice

In a sufficiently large organization, embrace Conway’s Law. Create software that mimic organizational structure, or modify organizational structure to mimic software architecture. Any other arrangement leads to chronic friction.

As a corollary, refactoring of organizational structure can be a forcing function for refactoring software architecture. It may take time, but your software will eventually reflect your new organization.

• #FridayDevAdvice

I made a topical cartoon.

• #humor
• #art