Thursday, January 23, 2014

Refactoring - the human factor

I talked to many people about the concept of refactoring recently. I've noticed a pattern. Not all team members are equally pro-refactoring.

I know how annoying it may be, when you're doing your best to improve the code, you learn how to do it the best way, you try to introduce it and then it's not only not appreciated, but also often rejected. Why is that?

There's plenty of reasons, but most of them come down to the fact that a project is a team work. In a team, we work with other people. We all share the same goal - to let the project succeed. However, we're humans - each of us has a different perception of the goal and the path that leads to this goal.

You may think that it's obvious that a better code will result in the success of the project. In most cases that's true.

You may notice different levels of the refactoring-scepticism.

Do we really need to change the existing code?

If you see such attitude, then one way of dealing with it is going back to the reasons for the refactoring. Is it because you spend a tremendous time on bug fixing? Is it because adding new features takes more and more time? Maybe it's because the app is slow and refactoring can help you extract some parts and later optimize them?

There's never refactoring for the sake of refactoring.

Whatever is the reason, make sure everyone understands it. If there's no understanding, move the discussion one step back. Why is it that your perception of the situation is different? Programmers are smart and logical people. Once you all see facts, metrics and numbers, it's easier to agree on the same solution.

Refactoring takes a lot of time

This is a fair argument. We all care about the time we all spend on the project. Even if it's you doing the refactoring, then everyone is aware of the fact, that this time has a cost.

The best way to deal with this argument is to keep improving refactoring skills. Both yours and your teammates. Examples from the Fowlers' "Refactoring" book are great. If you've done a quick refactoring, maybe it's worth showing to your team on a projector or record a screencast?

What you want is to have the refactoring cost being almost negligible. If your refactoring changes are fast and safe, then it's quicker to make the change than to discuss it.

I wouldn't refactor this part

I made the mistake of refactoring the part of the code that wasn't really that important to change. It depends of the time spent. It's always good to improve the code everywhere, but what is the price? Does it take you 10 minutes, 1 hour? 10 hours? 10 days? Is it worth it?

Time is our currency, make sure we spend them in the best way.

I would refactor it differently

This problem appears when we have different visions of the refactoring. Let's say you learnt everything you could about DCI and you're sure that's the best direction to go with your project. You envision the contexts, the roles, the objects. Slowly, you keep extracting more code into modules that are later (hopefully) used as roles.

At the same time, your colleague kept studying the concept of microservices. His goal is to split the app into multiple services talking to each other via HTTP/JSON.

Where you see contexts, he sees services.

This represents an architectural difference between both of you.

To be honest, this is a nice problem to have. It means, that people in your team are passionate. They put time into learning new concepts and they are constantly trying to image the app in a different way.

How to deal with it?

I've chosen DCI and microservices as examples, but you could have a much different pair. What matters here is that most of the good architectures are not in fact that much different, however surprising it may sound.

If you want to go DCI and your colleague wants to go microservices, then you have more in common than conflicts. Putting behaviour in the modules, as a step into using them as DCI roles is also a step into the microservices direction (you split the logic in a way that can be used by the microservice, later on). Your main difference is probably the last step - really, that's a nice problem to have :)


One last thing, sometimes you may resort to another option:

Don't call it refactoring

OK, this one is controversial. In some teams, refactoring have negative meaning. It's probably for good reasons. Maybe they've had someone in the team, who didn't deliver value apart from endless refactoring? Try to understand it.

The goal is not to 'do refactoring', the goal is to do better, as a team.

If it doesn't help you, don't call it refactoring. Some teams are totally fine with the idea of The Boy Scout Rule, which means more or less the same as refactoring. Keep improving the code quality, don't call it a refactoring.


Summary

No matter what is the reason of the initial misunderstanding about the refactoring, make sure everyone understands it the same. Most of the times, there's something rational behind the refactoring need.


----

What you just read is an excerpt from my book: "Rails Refactoring: Service Objects". If you're a Rails programmer and struggle with an existing not-so-pretty Rails code, then you may find it interesting. The book is 191 pages, full of code examples and with recipes how to safely, step-by-step improve your Rails controllers, even if you don't have a full test coverage. 

If you have examples of ugly Rails controllers, then please, send them to me: andrzejkrzywda@gmail.com.

Sunday, January 5, 2014

Twitter as a geek party

Why do I follow close to 2000 people?
Why do I keep complaining about the Twitter following limit (2000)?
Why am I active on Twitter?
Why did I just unfollow 150 people?




[UPDATE February, 2017]

This blogpost was written when Twitter was a great place for developers who were mostly interested in dev content. This was great for many years. As of late 2016, this has changed a lot. Even if you follow developers, you'll see mostly current politics content, usually US-centric. This means the technique described in this blogpost doesn't make sense anymore. Twitter is no longer an inspiring place for developers, who prefer to read about politics elsewhere or who prefer to stay out of politics.
----


Twitter is an ongoing, very inspiring geek party

I use Twitter in a bit of unusual way. Twitter to me is an ongoing, very inspiring geek party. It’s like a huge, virtual room (Snow Crash anyone?) , which I can enter, whenever I want. I do it every now and then for short moments. I click some links, I see the pics. Conversations are most interesting - I focus on those. What do people talk about? Is it interesting to me? Is it interesting to my work?

Because the topics of their discussions inspire me

I’m mostly connected to the Ruby/Rails community. Why do I follow PHP, Java, .NET people? Because the topics of their discussions inspire me. Why do they keep talking about DDD, when it’s a completely unknown concept in the Ruby community? Is it worth researching it? Can I join the conversation and explain how this problem is solved with Ruby?

I read about 10-20% of the tweets

2000 people is much, but not much if you want to get inspired from many different directions. I hate the Twitter limit - for anti-bot reasons, they put this limit of 2000, probably with the assumption that no one sane, would want to follow so many people. There’s a problem with this assumption. I do want to follow thousands of people, but I don’t want to read all of the tweets. That would be insane. Twitter is not my email - I don’t read everything. I estimate that I read about 10-20% of the tweets. I want to have this mix of people in my timeline. Ruby is a lovely community, but the discussions don’t cover all of the interesting programming topics.

t followings -l --sort=tweeted | head -10 | awk '{print $1}' | xargs t unfollow -i

There’s one thing about the Twitter limit. It gets bigger if I get more followers. In short, I need to have about the same number of followers as the number of people who follow me. I’m not far from that - there’s about 1500 people following me right now, but it’s still not enough. That’s why from time to time I need to clean up the list of people I follow. I unfollow the most silent ones, who didn’t tweet for the last year or so. It doesn’t mean I don’t care about them. If not the limit, I’d be fine. Given, my Twitter usage, though, that makes most sense. I can always follow someone again, if they get more active.

I can’t even describe how much value I get from Twitter

I’m so grateful to the people I follow. I learnt so much, I get inspired so often.

I want to give the value back to my followers. I try to be active, tweet interesting links, engage in good conversations. Teach someone. Actively listen to other people problems. Try helping.

I recommend you to try this approach. Follow more people (use Twitter search to find interesting people). Treat is a geek party. Get inspired. Engage more. Don't read everything.

If you're a programmer, you may enjoy following me - I tweet mostly about programming, JavaScript, Ruby and working from home.

(Photo credits: http://www.flickr.com/photos/romytetue/ )