Agile Attitudes- Eliminating code duplication

[agileattitudes at agilerules.com]

Agile Attitudes
Volume 2, Issue 1                                     Jan. 11, 2005
         A free bi-weekly email newsletter
                Brought to you by
             Agile Rules consulting
               www.agilerules.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Welcome to Agile Attitudes, a newsletter of ideas, insights and
technical tips that help people find better ways to develop
software. Feel free to share this with anyone - just be sure you
send or print the whole thing, including the copyright notice.

Directions for managing your subscription are below.

                 O><O><O><O><O><O
           Eliminating code duplication
                 by David Kramer

There are many "best practices" (golden rules) of software 
development.  Some don't make much sense, and some we follow 
without really knowing why, but some practices offer so many reasons
to follow them, that you wonder why anyone even needs to be
reminded of them.  Eliminating code duplication falls into that
last category for most developers, but it still pays to talk about
why it's a good thing, and why it doesn't always happen.

Why eliminate [nearly] duplicate code?

- Code duplication means more code.  More code means more time and
more opportunities for bugs and other forms of "unintended
functionality".  More code is also harder to read later and harder
to expand on.

- If you write code to do essentially the same thing in more than
one place, and you later need to change that code, you must
remember all the places it was implemented.

- Even if you don't need to modify the different code segments
later, slight differences in implementation in each
code segment can make your program work in unpredictable,
inconsistent ways.

- Writing code once helps encapsulate functionality.  This is
beneficial whether you're using an object-oriented language or not.

- If you have just one code segment to implement a particular piece
of functionality, it becomes much easier to share with other
applications, or other parts of the same application.  That, again,
means less code you have to write.

- Other developers trying to understand the code later will be
puzzled over how the code segments are supposed to differ, which
would be a natural conclusion.


Why doesn't it always happen?

- Insufficient planning: You may not have realized when you wrote
function A that function B will need the same functionality.

- Insufficient refactoring: Having discovered that function A and
function B need the same functionality, you may not do anything
about it.  Most times, this is "penny-wise, pound-foolish"
behavior.  You may get this rev of your software out the door
sooner, but tracking down the duplicated functionality
later when it rears its head as a bug will be much harder.

- Insufficient communication between developers.

- Insufficient support from management.  Some companies don't have
the vision to let developers spend enough time refactoring instead
of adding functionality.  But there is a defense: cold, hard 
numbers.  If you track the root cause of bugs, and can show how
many might have been caught through this kind of refactoring,
they will see the light.


How do you eliminate code duplication?

- Take the time to reflect on your codebase every now and then.  If
you don't get support from management, explain the advantages of
fixing potential bugs while the code is fresh in your mind,
catching more bugs before they're deployed, and making further
enhancements easier to implement.

- Write your software in clearly-defined layers, preferably either
infrastructure-first, or working towards the middle.  When you do
this, you will see the places you can share code.  If you write
your code from the UI-down, you won't find the infrastructure
elements that need to be shared, and you risk creating bugs in the
infrastructure, where they're hardest to find.

I hope I've been able to help you see the value of eliminating code
duplication, and getting others to join the effort.  Better code is
almost always worth it in the end. 


                 O><O><O><O><O><O
More articles on Agile software topics at http://www.agilerules.com
Within our company we have a sub-specialty in embedded systems.
Our site has articles on embedded XP and we support a discussion
list focused on the use of agile methods for building embedded
software. The list signup info is at
http://www.agilerules.com/mailinglists.phtml

                 O><O><O><O><O><O
To help you get started with in-depth research into Agile Attitudes
topics, we have added a Library section to our web site at
http://www.agilerules.com/library.phtml
Order using our links and receive discounts up to 30%!

                 O><O><O><O><O><O
If you enjoyed this issue or found it useful, forward it to a
friend! Help spread the word about better ways to build software.
Invite your friends and colleagues to join our growing reader
community at http://www.agilerules.com/mailinglists.phtml

                 O><O><O><O><O><O
Looking for a speaker for your next corporate or society meeting?
We present dynamic, informative programs on topics of interest
to managers and technical staff in their transition to more
flexible, robust ways to create software.

                 O><O><O><O><O><O
Want to reprint this issue in your company or society newsletter?
For permission to reprint any of the articles, contact us at
info at agilerules.com.

                 O><O><O><O><O><O

If you would like to receive an email as soon as we know of
an event in the Boston area of interest to the agile software
community, you can sign up for the announcements list at
http://www.agilerules.com/mailman/listinfo/agileannounce

                 O><O><O><O><O><O

Your feedback is welcome! Send feedback to info at agilerules.com

To manage your subscription:
http://www.agilerules.com/mailman/listinfo/agileattitudes

                 O><O><O><O><O><O
    Brought to you by Agile Rules consulting
      162 Marrett Road, Lexington MA 02421

         Copyright (c) 2004 Agile Rules
               info at agilerules.com

                 O><O><O><O><O><O
Privacy notice: We will not release a subscriber's address to any
third party for any reason. This is a strictly opt-in newsletter.
No one is ever subscribed without their explicit request.