Comments on: Riskiest thing first vs Outside in development

By: Richard Jonas

Richard Jonas — Fri, 13 Aug 2010 16:30:25 +0000

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).

By: Mark Wilden

Mark Wilden — Sun, 07 Mar 2010 04:24:15 +0000

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.

By: Tom

Tom — Sun, 07 Mar 2010 03:42:09 +0000

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.

By: Michael L Perry

Michael L Perry — Wed, 03 Mar 2010 13:37:06 +0000

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.

By: Helen

Helen — Wed, 03 Mar 2010 12:29:30 +0000

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.

By: INTPnerd

INTPnerd — Wed, 03 Mar 2010 04:36:40 +0000

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.