Wednesday, October 8, 2008

Inside Out vs. Outside In

I like to read code on paper. Some people only read code on the screen. I have at times wondered what drives each coding style. The reason I like to code on paper is because it helps me see the big picture. I get to take in all of the code. And it allows me to change venues when looking at code. For example I can print out a big piece of code and go sit in the park or lay on my bed, or sit in the kitchen, or whatever.

I find that being able to flip between pages and mark things and take notes on paper is invaluable for seeing the big picture, or what I would call “outside in” coding. I tend to code outside in, and I think screen only coders write “inside out”. When you write code inside out it means you start writing small functions and you just keep putting them together until you have something useful. Looking at the big picture is less important because you are always focused on one little section at a time and your project grows this way.

Inside out coding is great because you always have something working. The downside is that it doesn’t necessarily help you get to a radically different place. It is harder to chart a course this way. Similarly, writing code outside in has the downside of not necessarily having the benefit of rapid iterative development, and not necessarily seeing all of the opportunities and patterns that may arise from deep in the structure of the code.

I have come to believe that both styles of development are important, and that it is in fact helpful to have a mix of styles on a team. The idea is that inside out is great for creating building blocks, and the outside in thinking provides form structure and direction.

Part of the reason I am thinking about this is because there is a very popular school of thought that currently promotes iterative development, which is often synonymous with inside out development. I believe iterative development is great when you don’t have too far to go. But I think that big picture thinking, as opposed to a purely iterative process is invaluable to certain types of innovation and to getting to a less obvious place. Properly managed, inside out and outside in together can be a very effective combination.

7 comments:

I, Robot said...

Absolutely. Having worked in an Agile shop for the last 16 months, one huge problem with this approach is that product architecture suffers. You wind up delivering the storefront, only to find the aisles are too narrow, there aren't any bathrooms, etc.

Tommaso said...

I never printed my code, I think I will try. A question: do you print syntax in color?

Hank Williams said...

Tommaso,

I print on a black and white laser printer. I have often thought it would be interesting to print in color for the syntax highlighting, but I dont like inkjet for code as much, and I am not sure I could justify a color laser for such a pedestrian purpose.

neovive said...

A tablet PC might work well for this. However, you would need to wait for a Mac tablet. One with a dual-touch screen that would let you scroll around the code and write notes would be nice.

menriquez said...

that's why using a step debugger is so crucial...you get the best of both worlds.

you can see every project variable instantly, and see the execution, then step around the project for the big picture.

honestly, i don't know why more web guys don't use debuggers...you think your too cool or something to use "dads" debugger?

Anonymous said...

I used to do this a lot back in the day, but then it was a lot more useful having a tractor feed printer.

Anonymous said...

I partly agree on this. Yes, outside in is crucial for structure. No, i don't agree that iterative development per definition is inside out. In iterative projects i believe it is still possible to start with the big picture and then realize parts of the big picture in subsequent iterations.

Post a Comment