XNSIO
  About   Slides   Home  
 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
      
`
 
RSS Feed
Recent Thoughts
Tags
Agile agile bengaluru 2010 Agile Coach Camp agileindia agile india agileindia2012 Agile India 2012 AgileIndia2013 Agile India 2013 Agile India 2013 Workshops agileindia2014 Agile India 2014 agile mumbai 2010 ASCI Attendees Profile Code Coverage code smells Conference Continuous Deployment Continuous Integration cyclomatic complexity Design duplicate code Evolutionary Design Extreme Programming Industrial Logic Lean Lean Startup LinkedIn Open Source pair programming post modern agile primitive obsession smell Refactoring Refactoring Teaser Scrum SDTConf simple design TDD technical debt Test Driven Development Testing unit testing user stories video
Recent Comments
«

»

Redefining Legacy Code

Michael Feathers did a great job by redefining legacy code to: “Code without Tests”.

Over the years, I’ve dealt with code which had tests (unit, functional or both). Some of it was even test driven. But it was extremely difficult to understand and maintain the code. The code-base exhibited the same problems as Legacy code.

What does this mean? IMHO, it means we need to broaden our definition of Legacy Code.

Legacy code is code that developers fear facing. Legacy code does not communicate its intent and has a very convoluted design. It is code with high viscosity which encourages sloppy job by the developers and makes it extremely difficult for them to do the right thing. Abundance of Code Smells, lack of Tests, long feedback cycles, unpredictability, etc : all of these are contributing factors.

Related posts:

  1. Refactoring Legacy Projects: Scaffolding Technique If you’ve inherited a Legacy Project (project without any tests) and say you want to enhance an existing feature, where...
  2. Organizational Viscosity In the classical article named “Design Principles and Design Patterns“, Bob Martin (Uncle Bob) defines Viscosity and talks about 2...
  3. Unit Tests Validates Micro-Design I’m about to make a rather controversial statement now: “Developers who use purely inside-out avatar of TDD, .i.e. use unit...
  4. Code Smells or Code Screams? According to Joshua Kerievsky Code Smells identify frequently occurring design problems in a way that is more specific or targeted...
  5. While the debate on upfront v/s JIT design goes on… Most software “engineers“ (engineers in double quotes) don‘t set out to create “bad designs“. Yet most software eventually degrades to...
  6. Code should Express Intent and NOT Rely on Side-effects Consider the following code 1 2 3 4 5 6 7 8 9 10 public static <T> String join(Iterator<T> itr,...
  7. Checkstyle’s Strict Duplicate Code Check Rocks! Recently, during a project rescue effort, I introduced Checkstyle as part of the automated build. This morning I saw the...
  8. Why should I bother to learn and practice TDD? My 2 cents, based on personal experience: With TDD, I’m a lot more confident about my solutions. If I spot...
  9. On Process and Trust No amount of process can fill-in for lack of trust. IMHO one needs to focus on building trust and creating...
  10. Avatars of TDD Background Over the last one year, I have spent time pairing with various TDD practitioners trying to find their avatar...

This entry was posted on Wednesday, September 16th, 2009 at 3:17 PM and is filed under Programming, Testing. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.


    Licensed under
Creative Commons License