Based on an open space discussion at GOOSgaggle, Rachel Davies wrote this interest post on Is Working Outside-In Always Better? (in the context of TDD)

This is one of my favorite topic. So I’ll freely express my thoughts here:

When I was doing my little “Avatars of TDD” experiment, I found TDD practitioners could take the same problem and approach it using either the Outside-In or the Inside-Out approach quite nicely. Obviously each person had their preferences. Also the tool used, the choice of programming language and paradigm influenced their technique quite a bit. I could see trade-offs in both scenarios. So I don’t believe in ONE best way.

Personally I don’t choose just one style. Depending on various criteria (listed below) I choose which approach I’m going to start with. I & most programmers I know go back and forth between Outside-In and Inside-out.

I tend to make the decision based on the following criteria (just a list of things that comes to my mind right now, I’m sure there are many more criteria):

• Familiarity with the problem – How clear the problem & its solution is.
• Stage of the feature/Project
• Prior Knowledge/Experience with the technology stack and implementation details
  • If its completely unknown, one might spike it out or build a throw-away prototype. Having the prototype in front of you, can influence which way you start.
• Whether your goal is to go breath first or depth first.
• Whether your goal is to get low hanging fruits first (easy first) or core first (highest risky items first)
• Whether you are driving the design or validating the design (test driven or test first).

Inside-Out and Outside-In also applies at a product level. Which massively influences our development style. For Ex: if the original idea about a feature/product is about a core feature that needs to be built. We could start building just the core idea, getting feedback and then slowly flush out the rest of the system as we build inside out.

It appears to me that, this topics needs a lot of context. Any discussion outside that context might dumb down the importance of this topic.

When faced with Legacy Code, I’ve found 3 possible options to deal with them:

• Leave it alone for now: Very rarely used, code seems to work fine.
• Piecemeal Refactoring: When its difficult to understand what the code does and how it does what it does. Its time for safe, slow and cumbersome refactoring process.
• Rewrite: When its clear what the code does, but it very difficult to understand how it does what it does, it time to rescue the code by rewriting it from scratch. This can be applied at various levels (whole code base, single module, class or method).

To Rewrite or to Refactor?

One can easily spend hours or days trying to refactor some code, when clearly (in retrospect) rewriting the code would be a better option. Sometimes you decide its better to rewrite the code and end up implementing something that does not work in all situations or we miss out something important. Unfortunately there is no clear guideline when I would choose to refactor code v/s rewrite the code. The key to me is, if I understand what the code does not necessarily how it does what it does, then its time to rewrite the code.

Rewriting code: Play it safe

The analogy I use is, rewriting code is like building bridges. You know that the bridge helps you get from point A to point B. It might be very complicated and risky to use the bridge any more. But that does not mean you’ll go and blow the bridge apart. Instead you would slowing start building a new bridge along side. When the new bridge is ready, you would divert a sample traffic on this bridge and see if it actually works. If it does, then you migrate all the traffic to the new bridge and blow the old bridge apart.

I use the very same technique when rewriting code. During the process, I might leave the code working but in a much more messier (worse) state. During CodeChef TechTalks in Bangalore, Sai told me that he refers to this as an “Expand and Contract” cycle. You are temporarily expanding your code base so that you can come back and clean it up.

When I’m rewriting code, I find black-box style automated tests very helpful. If you don’t have tests, it might be worth investing the time to write a few.

Where to begin Refactoring Code

• Outside-In: Start from a higher-level and refactor (delve) into the crux
• Inside-Out: Start refactoring the crux and work your way out

At times its difficult to identify the crux and I spend some time exploring (via refactoring) before I can choose an approach. Tests can be a great probe to understand the code.

When refactoring legacy code, I usually use the Scaffolding Technique to break the Catch 22 situation (To refactor we need tests, to write tests we need to refactor). Scaffolding tests don’t necessarily have to be UI tests, I’ve used Unit tests as scaffolding tests as well.The key thing is they are temporary and meant to help you get started.

Thanks to the folks @ the Legacy Code BoF @ CodeChef TechTalks in Bangalore who prompted me to write this blog.