jump to navigation

Agile without Refactoring is like Racing without Pit-stops May 11, 2011

Posted by vivekbohra in Uncategorized.
trackback

It is often said that: It’s easy to write code that the computer understands but an art, to write one that humans can

How many times have you reviewed software code and ended up wondering “Just how on earth does the complier understand this?” and wished you too could think like the compiler.

In today’s world, we find that, there is mad race out there amongst ISVs to hit the market first with their innovative ideas and products.

Life is a race! If you don’t run fast, someone else is bound to step on you and race ahead.

  • Hence, it’s no surprise that ‘Agile Methodology’ has become the de facto standard for product development. There is no doubt that Agile has its own advantages:
    Provides early visibility into the development activity
    Ensures that features get implemented even before requirements can change
    Continuous feedback ensures that there is no guesswork required
    Product gets delivered in the least possible time (albeit with limited features)
    Leads to a satisfied customer

But, there are a few inherent disadvantages of Agile:

  •  It does not emphasize on documentation
    In the process to meet the sprint targets, the code often gets written only considering the current task at hand (without the holistic picture)

Here comes the savior: Refactoring. It is the answer to ensure code-quality is not sacrificed at the cost of speed. Consider the analogy of Formula-One race. The F1 team-manager has to determine the number of pit-stops that need to be taken during the race, by considering the fuel capacity of the car, tyre lifespan and most importantly the trade-off time lost in the pits versus time gained on the track through the benefits of pit-stops. Choosing the optimum pit strategy is critical for the success. As any unscheduled or extended stops in-between, such as, for a repair, can be very costly, as cars remaining on the track can rapidly gain distance on the stopped car.

It is a similar case with Agile development, as the code passes through multiple cycles through multiple developers eventually the code starts to smell, the Scrum Master has to decide when to take that Code-Refactoring stop in their SCRUM process. Before taking such decision, he needs to consider the most important trade-off of time lost in this cycle versus the time the team will gain due to the resulting improved code readability and maintainability while implementing new functionality with lesser defects.

Refactoring is the art of restructuring existing code by pursuing a disciplined approach, to alter its internal structure without modifying its intended external behavior, resulting in making the code-base more readable and maintainable.

Why Refactor?
Often code starts to smell, due to the following reasons:

  • Developers are more concerned with getting their programs to work, then they are about future maintenance or future development
  • New developers try to adjust their code-changes so that it does not impact any of the existing functionality
  • Junior programmers implement code changes, without being aware of the original developer’s approach

Frequent such code changes lead to loss of original design, code duplication, and eventually results in an unmanageable code. You can get today’s work done today, but if it’s done in such a way that you can’t possibly get tomorrow’s work done tomorrow, that’s when you start to slow down and lose the race.

Refactoring code is essential to continue with the rapid development. Not refactoring the code may show quick progress initially, but it will soon slow the process down, as it requires increasingly longer time for developers to:

  •  Understand the application
  •  Implement enhancements
  •  Debug and fix code (without introducing new defects)

Therefore, it’s of utmost importance that a ‘refactoring’ cycle be planned intermittently to make the code fighting-fit again for the next SCRUM cycle.

Benefits provided by refactoring:

  • Ensures adherence to OO-best practices / updated architecture
  • Improved performance
  • Increased code readability and maintainability
  • Increased readability leads to the discovery of possible defects
  • Help in smoother induction of new team members

So whenever you think of Refactoring, do think about the pit-stops, they are essential and an important step to ensure that you remain in the Race till the checkered flag!!

So guys, with this in mind, put the pedal to the metal… and make history in producing innovating software products!

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: