Włodek Krakowski has been a software craftsman for 13+ years. Recently he joined Ocado Technology in Krakow as an Software Development Team Leader and before this he spent 9 years in Sabre growing there from Junior to Team Lead Developer.
During this time he was observing struggles of teams he belonged to with delivering software for clients. What he noticed was a “complaints approach” to many things (like delays, lack of TDD, good design) and putting responsibility for this onto the other side (business vs development). For some time he decided to focus on “what I can do to change it”.
As he is developer he focused on teaching people refactoring code what was his role for the last 2 year. He focused on refactoring with given goal, not refactoring for refactoring. The goals were different : extendibility, separation of concerns, testability, maintainability or just readability which is core of each software but always with “the end in mind”.
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 workshop I would like to talk about Effective Refactoring.
Effective Refactoring joins two things : hand-on refactoring and talk about 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?