[agilesingapore] Open Space - Implementing agile for finetuning legacy codes

43 views
Skip to first unread message

Charmaine Chong

unread,
Sep 12, 2011, 12:56:18 AM9/12/11
to agilesi...@googlegroups.com

Sorry for the very late follow up.

 

The topic discussed during my session was around the options available for making legacy codes more maintainable and understandable.

 

Problem: the software was not well designed when started out 5 years ago with no proper documentation. As it was not well thought through, we faced a lot of issue maintaining and analysing the code.

 

Options available: rewrite, clean up the code as we make changes or prepare documents

 

It was suggested that the way to get out of this is to do a lot of unit testing and create test cases around the functions affected every time someone touches the set of codes. This will mean it will take longer to produce any new enhancements on top of it but it will make the codes easier to understand through testing.

 

It will be a waste of time to rewrite the product with the same features all over again.

 

 

 

Charmaine Chong
Executive Director, Development

DID:    +65 6304 7543

Mobile:    +65 9800 2927

Main:   +65 6304 7500
Fax:    +65 6474 5890
Email:  charmai...@lanworks.com.sg
Web:    www.lanworks.com.sg
Office: 6 Commonwealth Lane, #01-01, GMTI Building, Singapore 149547

LANWorks
IT from a Business Perspective
We want to do the best we can for you. Please let us know how we can improve by emailing me or my Manager, Abu Omar at abu....@lanworks.com.sg

 

Kenneth Loh, PMP

unread,
Sep 12, 2011, 1:22:32 AM9/12/11
to Agile Singapore
I look forward to the discussion of the topic.

On Sep 12, 12:56 pm, Charmaine Chong <charmaine.ch...@lanworks.com.sg>
wrote:
> Sorry for the very late follow up.
>
> The topic discussed during my session was around the options available for making legacy codes more maintainable and understandable.
>
> Problem: the software was not well designed when started out 5 years ago with no proper documentation. As it was not well thought through, we faced a lot of issue maintaining and analysing the code.
>
> Options available: rewrite, clean up the code as we make changes or prepare documents
>
> It was suggested that the way to get out of this is to do a lot of unit testing and create test cases around the functions affected every time someone touches the set of codes. This will mean it will take longer to produce any new enhancements on top of it but it will make the codes easier to understand through testing.
>
> It will be a waste of time to rewrite the product with the same features all over again.
>
> Charmaine Chong
> Executive Director, Development
> DID:    +65 6304 7543begin_of_the_skype_highlighting            +65 6304 7543      
> Mobile:    +65 9800 2927begin_of_the_skype_highlighting            +65 9800 2927      
> Main:  +65 6304 7500begin_of_the_skype_highlighting            +65 6304 7500      
> Fax:    +65 6474 5890
> Email:  charmaine.ch...@lanworks.com.sg<mailto:charmaine.ch...@lanworks.com.sg>
> Web:    www.lanworks.com.sg<http://www.lanworks.com.sg/>
> Office: 6 Commonwealth Lane, #01-01, GMTI Building, Singapore 149547
>
> LANWorks
> IT from a Business Perspective
> We want to do the best we can for you. Please let us know how we can improve by emailing me or my Manager, Abu Omar at abu.o...@lanworks.com.sg<mailto:abu.o...@lanworks.com.sg>

Panwei Ng

unread,
Sep 13, 2011, 1:04:40 PM9/13/11
to agilesi...@googlegroups.com

Hi,

 

I did not attend the session, but I hope I can contribute something useful here.

 

Poor legacy codes that are not understandable is a common problem. Heavy investment into refactoring will not work if the development team has poor coding habits. Every line of code  they write becomes legacy code the next day, or a week later. Thus, even if the team do take the time to do major refactoring, the code gets degraded very soon.

1.       Stop code degradation. This means that using the current set of codes as a baseline, any further modification should not make it worse. This can be achieved through using such as code metrics – like McCabe complexity, lines of code per method or file, etc.  So, get people into the habit of writing good code from now on.

2.       Once you have code metrics in place, you can look at areas that need improvement. If you are using refactoring tools, the tools guarantee that changes will not break the system. This is only useful for simple refactoring, not major ones. However, still it is a good start. Again, the whole idea is to have to get into the habit of writing good code and tidying up.

 

Of course this is all easier said than done.

 

Cheers

-- Pan-Wei Ng, Ph.D.

   Ivar Jacobson International

   pan...@ivarjacobson.com

   +65-9772-3538

Steven Koh

unread,
Sep 15, 2011, 2:04:36 AM9/15/11
to agilesi...@googlegroups.com
This is what worked for me & my team.
1) For future enhancement and major bug fixes, put the new code in a new namespace/package. 
2) Immediately add source code analyzer (like FxCop and StyleCop) into this new namespace. Unless good coding habits can be enforced with minimum hassle (through CI technology), good coding habits remain philosophical and non-actionable.
3) With every little enhancement and major bug fixes, move the codes from the old namespace to this new & clean namespace. 
4) This is an excellent training ground for your weakest/most junior developers because:
    a) You have a functionally working system for them to compare/validate against the clean up code base.
    b) Therefore, working test cases can be easily derived for them to learn TDD.
    c) To reinforce (b), since there is nothing preventing them from improving the code base such as vague user requirement, and other external factors. This is a good opportunity to see their potential if left on their own. As usual, there will be the mediocre, perfectionist, over-engineering/gold plating, full-of-excuses....
Reply all
Reply to author
Forward
0 new messages