This post is not for people who take life too seriously, and not for people who know the answer to the ultimate question about meaning of life.
This post is not for people who don’t get Monty Python jokes, and not for people who do not get sarcasm, take everything personally, and who don’t share this vision,that life is just a ride.
I promised myself, that my next post will be about some nice framework, or some important architecture pattern or challenging technical problem,like reliable multicast or exclusive consumers, my little two daemons, my Moirai, my own personal road to hell.And again I have failed, failed to not get distracted by Twitter and blogs 🙂
So this post is my own take on “megasoftwarecraftsmanshipper”, strategic refactorization and somehow lously coupled with latest discussion between Uncle Bob and Ted Neward.
Reading through last tweets and blogs I realized that I have just one advice for us.
Do you think that I have some secret trick which will change your refactoring “kung fu” forever? And I am going to share it with you? No way. There is no magic, unless you call “critical thinking” magic. It is a really hard job to do, it requires special skills (like “Extract Method” spell, or magical items like “Wand of God Object” which shines every time you get close to “God Object”). It is a job which requires mixture of knowledge, experience and courage.
It is job which will give you headaches.You will loose faith in human race. You will cry, shout and laugh at the same time and you will earn respect in da hood.
That’s all and nothing more, because it is garbage, really. Only you care about it, and you know what? You throw company money with every run of your useless tests suite. Did somebody ask you to do it? Really? Don’t lie yourself. You could develop next shiny feature with the time you wasted for refactoring.
Yeah, I know somebody will have to maintain it, but lets be honest, it will not be you, so why bother? (you get the sarcasm, I hope 🙂 )
Is this some kind of “refactoring” bashing? No, it is not. I really think refactoring is a waste, this is just a painkiller, not a cure.
You feel better because you are a “craftsman”, you care about your habitat. In your mind filled with “craftsmanship manifesto”, not doing refactoring, is like throwing pieces of paper on a sidewalk, like not helping animals in a cold winter night.
Your management is proud, because they understand “technical debt”, they can fill reports with numbers about money saved, thanks to their strategic skills and investments.
And your customer doesn’t give a …. about it.
And you know what? You behave like compulsive, addicted jerk. Yeah, me too, no worries it is my fault too. Because you keep coming for more, every line of “wasted years” you see, you feel this addictive shiver of temptation, to make world a better place, to bring professionalism back to life,”to shine like a crazy diamond”. You are so blinded by your filthy thoughts about getting rid of “shared global state” and replacing endless “if” spaghetti structures with Strategy pattern, that you don’t see that this is the same code you worked with 3 months back, when you were working on previous release. You are addicted, and refactoring is your drug, and you keep coming for more.
Take a look back at your SCM logs, haven’t you worked on the same files few months back? You keep coming to the same places in the system, over and over again.You fix and improve, but system erodes so fast, in so many phantasmagorical shapes, that you don’t even recognize that you have been through this nightmare so many times. Stop refactoring and step back, and realize that what you see here is fix that fails, another lovely “system trap”.
Let me explain you why your lovely fix fails, and I am not going to bore you with systems theory and their explanation, no worries.
You make corrective actions in the system (you call it refactoring), and you see immediate effects, you feel better, complexity metric is at right level,and you know it was good. You improved it and you moved on. You forgot about side effects of your changes, you forgot about cause and effect.Somebody got your changes, junior person or “Sunday” coder. It really doesn’t matter. What matters is that they had to add some nice customization for important client and they became mentally damaged in a moment when they opened your changes. Your “clean code” was sooo clean, that they were afraid to touch it, so they “copy pasted” old version, added customization for customer, added one small ‘if’ in the beginning of your freshly refactored code and moved on.
You know what will happen the day you will open this “masterpiece”? You will sing along with Brittney, “Ooops I did it again”, admit it. You will refactor it, using more and more “spells” and magical items. It will be even worse with every cycle.
You have to break this addiction.Stop refactoring! and ask yourself, why do I have to refactor? Code is old, project to complex, lack of design, deadlines or technology stack… it is what it is. The important thing is that you can improve code without touching it, almost.
Organization is what you need to refactor in first place. It doesn’t mean you have to fire management, and become “usurper CEO”. You can start from your team.
Architect you organization in a way you will not have to refactor in a endless loop. Share knowledge, respect others and improve your own habitat, which is not your code but your team mates, your manager and architect. Does it sound like a utopia? Maybe, but isn’t it nice?
Or maybe if you are on a senior, lead, architect or principal position, this is what you should do? Not just only bash people for their misunderstanding of your great ideas? For their misunderstanding of your addiction to refactoring, SOLID principles, low coupling and so on? Easier said then done.
What should I do? Listen to the wise man, look outside of your comfort zone and understand that this is not problem with people and their skills or attitude. Maybe this is just manifestation of your organization structure. Give this thought a chance, let it grow. Maybe you have to constantly refactor, because people know that you will fix it anyway? Because they don’t have time? Because they don’t care? Because we don’t do thing like this here?
Don’t get me wrong. Refactoring can be a cure for lot of your problems, but only when you have organization which needs cure not painkillers.
Refactoring as a short-term solution, quick fix, will not help you. It will make things even worse, craftsman will become more skilled, and junior people more confused.
It can even lead to a silent war between “craftsman” and “workers” camps, and both will try harder and harder.
“Craftsman” will use more and more sophisticated refactorings, structures and patterns, and “workers” will play “ignorance game”.Believe me I was in a middle of such silent war. Refactorings were blessed only in a situations of critical bugs and customer escalations, and this organization strategy didn’t work.It was not a good place to be, and believe me I don’t care if you are a “craftsman” or “worker”, and I don’t respect others more or less. This is who we are, this kind of diversity is good, but organizations should learn how to use it.
Refactoring as a daily habit, between sips of coffee and planning and demo sessions will improve you code, your habitat. Refactoring in a small, energizing “shoots” will make you a drug addict. So, stop refactoring of code and refactor your organization.
Nifty. I was wondering where you will lead on with “Stop refactoring”, this is nicely pulled off.
Thanks for thinking differently! I wrote about something similar recently, about how code quality is not a sacrosanct thing. Sometimes we write terrible code but we’re better for it:
Thanks, interesting post. Please could expand when you say at the bottom: “So, stop refactoring of code and refactor your organization.” ? How should the org be refactored?
This is long and complex topic, there is not enough space in a single comment :), but I think the most important thing for me is that every “system” be it human body, swarm or organization should be “self organizing” to be effective. Why? because self organizing systems respond to change faster, they can adopt faster to changing needs and environment. How we can achieve “self organization” in an organization? Crucial “ingredient” of self organization is feedback, without it, you as an individual or team or whole organization will not make corrective actions, will not improve, and this is where most organizations and we as individuals “suck big time” and we call “feedback” something that is just one big “blame game”. I maybe wrong but first step in any organization to “refactor” it to stop “blame game”, pointing fingers. I know that it’s hard, especially when you have remote teams, because this is situation when you can “blame” without a need to say it face to face, it is so much easier 😦
From my experience, “blame game” hides “real feedback”, thus organization doesn’t change, doesn’t learn, doesn’t adopt. Once you stop “blame game” you will start to hear real feedback, which can show you ways to refactor organization.
Thanks, I hope you write more about this topic!
I think that refactoring is a delicate theme, not just a technical issue. By refactoring you are destroying what collegues may have written. And also the egos, priorities…
But the fact is that code may have evident duplications, lack of generalizations … so your point which is? a) not to refactor at all b) explain to others what needs to be refactored,
(cont.) organize coding events with the team?
I think you got the point, too often refactoring is one man job, who usually sits in a darkest corner of the office, and he/she communicates with external world using high WTF per minute. This way first, “inconvenience is not shared” (this is not my sentence:) ), so people don’t understand what needs to change, what needs to be improved, secondly knowledge is not shared. At the moment we are trying to make refactoring more collaborative effort. From time to time we book few hours during the day, we close with team in a room and try to refactor code using one laptop and projector, we switch keyboards, so everyone has a chance to refactor. People in our industry need to learn to give and receive feedback about their work, and understand this is not “blame” game, but opportunity to improve, for free :). The trick is that organization needs to support it, so this where refactoring of organization comes into play 🙂
I will try to write more about it in coming weeks, as this is really hot topic these days for me.