Mark Needham

Thoughts on Software Development

Riskiest thing first vs Outside in development

with 7 comments

I had an interesting conversation with my colleague David Santoro last week where I described the way that I often pick out the riskiest parts of a story or task and do those first and David pointed out that this approach didn’t seem to fit in with the idea of outside in development.

The idea with outside in development as I understand it is that we would look to drive any new functionality from the UI i.e. the outside and work our way inwards through the various layers and probably eventually end up with persistence i.e. the inside.

In the particular example that were basing our discussion on I described a story that I was working on with my pair where we needed to apply some constraints to certain items in our data set and then display them differently on the UI as a result of that.

We went through the existing domain model to see if there was anything in there that we could make use of, and having realised that there wasn’t anything we mapped out the tasks we would need to do to implement this functionality.

The most difficult/tricky task was to handle the data migration as we realised that we would need to add an extra column to one of the tables. We also needed to do the associated Hibernate mapping and the code from the UI and controller level downwards to make use of this.

We did the data migration and associated work first and one we were happy that was working we went and coded from the UI downwards until we reached the persistence layer.

In this situation it seemed like it worked out reasonably well and I couldn’t see that we would have ended up with a different solution if we had started off driving through the UI.

In fact we did end up spending most of our time doing the data migration so to me it seemed somewhat justified doing that first since we did run into a couple of problems.

Outside in development in general seems a good thing to me so I’m curious as to whether I’m justifying a sub optimal approach to myself or whether there are some situations where we can vary the approach a bit?

Be Sociable, Share!

Written by Mark Needham

March 2nd, 2010 at 10:49 pm

  • INTPnerd

    Very interesting. I think you did it the most reasonable way. Both the outside in technique and the risky thing first technique have advantages. This way you were somewhat combining the two.

    I tend to do outside in development a lot. It is especially helpful if you have not fully decided how the features are going to work. Even if that is not the case, it still has many advantages. You tend to write the very high level code first, which decreases the amount of change and refactoring you need to do later. As you work your way inward, it is not very common that after finishing more inward code you need to go back to more outward code and change it as a result. However if you go inside out, then it is very common that you need to frequently change and refactor your more inward code as a result of the implementation of the more outward code. This is similar to the reason that people say TDD results in better design.

    There are advantages of doing risky stuff first too. You more quickly get an idea of how long it will take you to get that part done and how difficult it will actually be, eliminating unexpected surprises later on. Some of the other advantages of this are similar to the advantages of the outside in approach. The riskier stuff is more likely to require a more creative and elaborate design. By designing it first you can at least make a design that is in and of itself as clean as possible. The complex nature of the risky code might make it better for the design of the risky code to influence the design of the more outside code, rather than to have the design of the more outside code influence the design of the more risky code.

    I see the main issue as this question: Is it more important to have your risky code well designed, or is it more important to have your high level code well designed. I believe the answer depends on how risky the risky code is. If you choose to implement the risky code first, you should probably do TDD because that at least helps you to better consider how the interface will be exposed and used by the more outside code.

  • It seems like outside in is a way of doing the riskiest thing first, since the UI is the part with the biggest risk of changing once the feature goes from being an idea to being something concrete that people can see.

    I think it’s good to have multiple approaches in your toolbox. I don’t think there’s one that’s going to work best in all situations. 🙂

  • While there is no right answer, I tend to favor outside in for new features, and riskiest first for known features.

    Outside in helps me to understand and discover the requirements. It gives me rapid feedback from stakeholders and validates my data model before it solidifies.

    Riskiest first, on the other hand helps me to solve difficult engineering problems. Instead of searching for the correct requirements, I’m searching for the best technical solution. The risky parts of that solution inform my decisons better than the safe parts.

  • Tom

    Outside in does not mean “all” of the outside first. You can start with minimal functionality and then drill down in a vertical slice. That way you deal with all the risks at all the layers sooner. So you can have your cake & eat it too 😉 and have something to show for all your hard work earlier.

  • Mark Wilden

    The reason that the approach you chose worked is because the UI you were driving for didn’t change. You had an idea of what the program needed to do, you chose to do one of the implementation details first, and you were right about what the program needed to do.

    Where outside-in wins is when you realize, as you’re developing the UI, that you were wrong about what the program needed to do.

    The UI is the only thing that really matters. If human beings get the output they want in response to their input, it doesn’t matter how that output is created. The output is always the most “risky” part of an application, because it *is* the application. You must get the output right, or you’ve wasted your time. Therefore, it makes sense to do it first.

    Everything else is just a means to an end.

  • I like to create a horizontal and vertical prototype. The horizontal prototype creates the UI and from this additional user stories might emerge.

    The vertical prototype proves the layers of the system and any external components we need will work together. If some don’t then it’s a risk that needs to be addressed early (especially if some components aren’t in our contol).

  • Pingback: Vertical/Horizontal Slicing at Mark Needham()