Skip to main content

Refactoring for sale

Among the technical list given by Mikael Boman in his post dedicated to product owners, "Practice #4: Refactoring" is for sure, the most difficult to agree with. Version control system, Continuous integration, Automated testing are concepts around tools, consequently their deployment has a visual, understandable, palpable result, so there is no worry justifying their costs.

If you don't get the Practice #6: Collective code ownership, wait for a few years until developers leave your company and then you will get it.

Simple design:
While the indicated article focuses on product owners, the simple design concept is obvious to many of us, but developers could feel it as a bridling of their creativity. While we all need to establish a software knowledge culture, where ideas around code design and patterns are understood, we face a dilemma when it comes to asking for simple creation. I didn't find a good way to recommend, but practices like pair programming and code review can mitigate the ugly and the glittery code. A developer conversation while looking at the code, will free the product from the lack of conception or avoid the all "design patterns" in one "software product" idea.

Previous to entering into the agile/lean world, I didn't find a proper solution to justify a moment to improve the code. Then, based on Lean concepts, I felt desperate because spending time on refreshing the code could be understood like a waste. But the only reality resides in understanding the technical debt and the product complexity.
Some people will argue the refactoring must be embedded in the development tasks and will state that concerned developers will perform this activity by themselves. But such behaviour could hide the iceberg from the product owner or give him a great argument to play the ostrich.
Refactoring must be understood, and the product owner must commit to spring cleaning the code.
If some tasks related to code refactoring are present in the product backlog, it means:
  • Developers have an understanding of the code, so the concerned component is not something anybody would touch anymore due to its ugliness, but only a huge number of code lines that smell bad.
  • Product owner has stepped back, understood the complexity of the component and admitted the technical debt must be lightened,
  • The regression linked with the refactoring will be mitigated by guardrails, like unit tests or user scenario rechecks by testers. Because the testers will have to valid the refactoring tasks, they would have discussed the impact and the use cases affected by this work with the developers. They will not discover the regression nightmare later after a refactoring decided by the developer on his own.
Pragmaticmarketing: Six technical practices you should know about
Scrumalliance: The top six technical practices every Product Owner must know about
Wikipedia: Code refactoring
Wikipedia: Design pattern
Martinfowle: MF Bliki: refactoring
Theagileexecutive: Technical Debt: Refactoring vis-a-vis Starting Afresh « The Agile Executive
Infoq: Refactoring is a Necessary Waste
Agileinaflash : Agile: In A Flash


Popular posts from this blog

Learning about Data Science?

This is the end of a beautiful summer, and also one of the warmer recorded in France. I’m continuing my journey in the product management world and today I’m living in the product marketing one too. I will blog about this later. During this first half of this year, I read several articles on big data and started to understand how important the data science discipline is. Being able to define a direction/goal to search, collecting the proper data, then using a collection of techniques to extract something others can’t see - it sounds like magic. Also, when I listened to the Udacity Linear Disgression podcast episode “Hunting the Higgs”, I understood people with these skills can be better at solving a problem than the domain experts themselves. Katie Malone explained that in a competition to solve a particle physics problem, the best results came from machine learning people. Then I read the article about Zenefit on the vision mobile website : “Zenefits is an insurance compan

Didn't register yet to the European Agile event 29-31 August in Paris?

I tell you, I’m not an expert in agile, just someone who found solution to my professional problems using agile methodologies. If you are convinced too and want to move further, please join us at the end of august, for a lot of open discussions and fun. Things are moving forward in the ALE 2016 organisation. Already, a great diversity of people answer to our call as shown below, but we need more. Yes the ALE 2016 will be great as it has always been since 2011 in Berlin. For those who do not know about the yearly ALE event, please find below a few tips. What is it?  If you do not know yet about the Agile Lean Europe event, here a few tips. ALE is a event for practitioners, meaning people who already practice agile methodologies like developers, modern CEO, teachers, leaders, etc.  Sharing ideas and solving problems are the ALE mains goals: people can propose topics where they share their experience, other can ask to solve a problem the can’t alone  The event formats helps

Unconference Agile Lean Europe 2016 (Paris) - Laissez vous porter.

No EN version yet here, sorry.  Second version. Précision du principe de communauté pour résoudre des problèmes. Ceci est un message personnel à toi qui serais dans le doute par rapport à ALE2016 . Il y a quelques semaines, j’étais à Mix-IT , une conférence de développement informatique / organisation, pour assister Yves Hanoulle dans l’animation du jeu The Scaling Ball Game . Durant les conversations hors des sessions, j’ai échangé avec différentes personnes sur le prochain événement auquel je vais participer : ALE2016 , A ma plus grande surprise, j’ai découvert qu'ALE impressionnait, faisait peur ou était incompréhensible pour ceux qui n’avaient pas encore jamais participé à cet événement. Mon message est simple : Laisse toi aller, viens à ALE2016. Durant les 5 premières premières sessions dans chaque coin de l’Europe, les remarques ont toujours été les mêmes. En repartant, tu auras : Découvert des participants qui sont tous très abordables. Tous viennent à cet évé