Category: Software Engineering

Clean Code or Code Clean – Why I love refactoring

I am pretty sure that most of the times, us developers have heard the following line from some senior personal “Why don’t you code it clean the first time”. Well in fact I have heard this many times as a developer and have told this to my juniors many times as well.

But when you dig deep, you begin to ask your self, Is there anything called coding clean these days. With the business demands, systems evolving, pressure to fix or develop faster etc… we as developers are tide down to quickly hash code and release! in fact all these new Agile methodologies and time boxed sprints are not making it any more easier.

So how do we make sure that we keep our code maintainable, clean and effective… We use a simple term called “Code Refactor”.

So what really is refactoring…

“Code refactoring is a “disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”,[1] undertaken in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.”  – Wikipedia

“By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you’ll find that it is easier to extend and maintain code.” —Joshua Kerievsky, Refactoring to Patterns
 
According to studies done the highest cost in a software project is in maintaining the code rather then writing the initial code. So refactoring is a critical art that needs to be practice. But most people do not treat code refactor as a software development routine to ardently follow. Many developers I know believe that refactoing is this BIG project that needs to be done as a separate project and needs a separate time / sprint cycle etc… I always believe in the idea that if you want to be agile or be in the agile space you need to refactor. 


With this in mind following are some key points that convinced me why code refactoring is a must in software development

  • I cannot be Agile if my code is not clean. Because I can not respond to change fast if my code sucks.
  • No one can write good code in one sitting, there should be several iterations. Each iteration cleans the code.
  • Code is there to be read and understood. We read code more then we write.When pushed with tight deadlines it is not possible to write clean code. So it’s better to write crappy code that works, then refactor to make it a great code. 
  • Managable and clean code has to have four characteristics and refactoring paves a way for that. The characteristics are
    • Simple
    • Clear
    • Bravity (Keep your code small)
    • Human readable then machine readable.
  • Software change over time. Hence designs and architectures change. The code also needs to support these changes. Hence the code will always get changed.
  • Your team depends on your code now and years in the future as well. So make it easy for the team by cleaning your code overtime.
  • The easiest code to QA or manage is code that is not there. Cleaning code, reduced unwanted code. This leads to less QA and less maintenance.
  • Finally, The code we write reflects us, leaving a cleaned code reflects our quality and who we are.

I hope the above shows why code needs to be cleaned continuously. The following are some tips when doing code refactoring that I normally try to follow.

  • Refactor your code as soon as you write your code. Don’t wait till end of a sprint, six months down the line to refactor.
  • Before doing any refactoring, first find a way to test what you refactor. Either find automated tests or build your own test for the area that you are refactoring. This could be unit, integration or functional tests. Never get into refactoring if you cannot test.
  • Don’t try to refactor the code by making it clever, but by making it simple
  • Refactor the code to be cohesive. This means that your code blocks should be doing independent work. Remove all dependencies as much as possible.
  • Make your methods to one level of abstraction. This means code your methods to have one functionality, and drill down to inner methods for sub functionality.
  • A method should always be fully visible within your screen. This means without scrolling up / down you should be able to read the full method. If a method cannot be read in one glance, then refactor the method again.
  • When refactoring, always try to reduce code and not add code. Code that is not there create lesser bugs. For example remove duplicates, remove redundant code, take out unnecessary comments or logging etc…
  • Checkin your code very frequently. 
  • Get help from a peer, to review your refactor.


I hope the above tips help you to improve your code by refactoring and continuous cleaning. Always remember that you are the creator of your code, hence make sure that you groom your code contentiously. Your customers or management may not see your code and will not care about code quality, but you will need to care about your code.

5 Attributes of a Great Software Engineer

Software Engineering is the process of applying engineering to design, development and maintenance of software. Most engineers who come from engineering schools are taught about engineering practices, programming languages , coding standards etc… but once you enter the world of professional software engineering and the dust settles down , you find the rules of the game are not exactly what you expected.

In the last 15 year I have dealt with software engineers who are rock solid , enjoying every minute of their work and others who are dreading to come to work everyday. After discussing and researching on both sides of the fence, what I have seen is that it is not the difference in skill set , the talents or IQ that makes the difference between the two , but the attitudes and the personality attributes that count the most. Listed below are five of the key attributes I’ve found that makes the biggest differences between the two groups

Passion

All great software engineers have a passion for giving solutions to variety of complex problems. It is in their nature to give solutions and they do not back down from challenges. Let’s face it, software engineers have either just finished solving a problem or are in a problem or heading towards a problem. So you need to have passion to find solutions to these problems. The solutions could be a software design, an analytical / logic design or a code change. But whatever way you look at is you need to have a passion for going into problems and giving solutions. If your cup of tea is not giving solutions to complex problems, then software engineering may not be the right hat for you to wear.

Desire to learn

Any software engineer I have come across who is worth his salt desires to learn. They desire to grow and expand their skill set as well as understand what their giving their software solution for. In order to do this a software engineer needs to have burning desire to learn.

If as engineers we are not sure of what solution we are developing we need to learn what we are developing our solution for. We need to learn what the requirements are. Gone are the days when an analyst would list down the specifications step-by-step with the intent of getting it developed in that order. Agile Development is an excellent example for this. It is expected for a software engineer to learn from clients and develop a solution that caters to clients needs.

The technologies in the industry are changing ever so rapidly that it is extremely hard to keep up, but as engineers it is expected. So desiring to learn and spending at least 1 hour per day on building themselves is key to any software engineer. They need to make sure they are in par with the industry needs and the latest technology , engineering trends.

How do you learn, well the best ways are

    • Ask Questions
    • Join a User group
    • Read
    • Try things out

Discipline

They say there are two pains in life, the pain of discipline which weighs ounces whilst the pain of regret which weighs tons. A true software engineer is totally focused and disciplined. Disciple is the difference between a cowboy and a seasoned engineer. I believe there are two areas that a software engineer really needs to be disciplined in

    • To end what you start – You need to make sure that you complete things that you start, otherwise you will have foundations laid down allover but no building to show for that. With the technology changes and new challenges that are thrown to engineers by the industry, it is easy to get lost in trying out new things always. But it is extremely important to finish what you start. As a software engineer you need to have a reputation as a person who the industry can depend on to deliver and that does not come if you are not disciplined.
    • To look before you leap – You need to think and see what are the consequence of doing something before doing. My metaphor for this is “Read the README before running the Software”. Most software engineers jump into something without doing the due diligence and this is asking for trouble down the line in any project. You need to spend that upfront time in planning (maybe not 100%) at least to a level where you know what needs to be done, where the potential road blocks can be and what can be done to overcome them. Sometimes you may not foresee all the challenges, but that is not in your control. But you need to be disciplined to spend that time upfront in planning before implementing.
    • Learn from your mistakes – You need to be discipline enough to document what went wrong with each project and see how you can improve on this. Most of the time I have seen engineers make the same mistakes over and over again. This leads to loss of credibility and potentially damaging projects. So as a rule make notes of what went wrong and improve with every step you take. This requires a discipline to document , analyze and above all commit to improving yourself.

Flexibility

I have herd the term “I am a Java engineer” , “I am C# engineer” , “I am Python engineer” or “I am Database engineer” , “I am a Business component engineer” etc… so many times by Software Engineers. For me this is not what a software engineer should stand for. A software engineer should be flexible enough to adopt change. They should be able to learn and see what the current situation requires and becomes the very agent that provides the solution. Now you may choose to master an area of expertise, but you should not get locked to any. The more flexible you are in changing yourself to the current needs of the industry the better solutions you can give and more you will be valuable to the industry.

Apart from this a software engineer should always try things out and see how they will fit into to the solutions that he needs to give in the future. Do not be afraid to change or try new things due to future failure. Always be flexible and adaptable.

A good software engineer is not bound by a technology, a framework or any area of development. They provide solutions to the industry by looking at what is best suited and how best to get that solution implemented.

Enjoy

The last but the most important attribute I have seen by solid and successful engineers is that they enjoy being a software engineer. They love and thrive on the solutions that they give and what they are called upon to do.

They enjoy what they produce and how they go about producing great software solutions. I believe they actually view the work they do as an art rather then just a profession and this leads them to enjoy the process of creating their masterpiece.

So enjoy every moment how challenging it may seems at the time. Remember somewhere in the not to distant future you will look back in time at a challenge or some problem you went through and laugh at what you faced and how you overcame , so why wait… why not just enjoy the challenges and what you do now it self.

So there you have it, five attributes that I have seen over and over again from rock solid engineers. I know if you add these attributes to you , maybe you can also become one rock solid engineer.