Effective Refactoring

Balance - this is the word we can hear in lots of places but not too often in software development. But what balance can you talk about in our industry? What is the balance we need/ How can we achieve it? Marketing people needs to have a product they can sell, developers needs to have a product that is easy and nice to work with.

How can we take care of this balance? Who should take care of it? Can developers only complain “if only I had more time I would write unit tests… / I would take care of the design / the code would be in better shape...”? Did you hear such complaints next to your desk? So what can we do about the above? It is enough to be a good developer or do we need something more?

In my talk I would like to talk about Effective Refactoring.Effective Refactoring joins two things : refactoring and effectiveness. Refactoring is a means to achieve the balance between production (clients receives working product) and production capability (developers are able to extend the product and deliver new functionality). Effectiveness is the mental approach to achieving our goals. Only when you join them you can act reasonably.

My goal is to encourage people to change the approach to work by refactoring when needed, by making it everyday practise or a habit. Each of us want to be happy at work. We want to be motivated but do we take care of it? We want to have good quality code, covered by tests, object oriented but what we really do to achieve it?

I would like to show 7 Habits of Highly Effective People presented by Stephen Covey in his best seller and how they can be applied to software engineering. Here are they.

Be proactive

Are you waiting for things to be done and complaining? Are you part of the solution or part of the problem? “It’s not me - it’s the team”. Did you hear this complaint?

Start with end in mind

Do you ask yourself questions : what I am doing? how should I do this? why I am doing it this way? What will be the outcome of my decisions in the near future? Did I really saved time if I skipped refactoring and quality although the product “is working”?

Importance before urgency

Certainly sometimes we need to put off the fire at work. But what kind of a motivator it is? “Must do it” vs “want do it” are two different approaches and if you want to use the latter approach you need to to really proactive and minimize the number of fires. Then you will have more freedom to take care of your code.

Think Win - Win or No Deal

What is your approach to collaborators? Do you perceive your (product) managers / marketing as competitors (time vs quality) or members of one team that drives together towards the success?

Understand before being understood

How to approach dealing with legacy code? Do you just add you new functionality or consider refactoring before or after this? What you do before you decide to improve the design? Do you want to understand the current state before proposing / imposing your changes?

Introduce synergy

Do you understand the difference between compromise and synergy when two people have different opinions and want to achieve agreement? Team can benefit a lot if people are looking together for “third solutions” instead of competing.

Sharpen the Saw

Do you take care of yourself so you are able to make it better? Do you know the areas of yourself to grow (physical, mental, emotional, spiritual dimensions). Do you know that sometimes to be better in refactoring is to stop refactoring?