Is Working Outside-In Always Better?

On Sunday, I went to GOOS Gaggle, a micro-conference on the development ethos described in  "Growing Object-Oriented Software Guided by Tests", the new book written by XP stalwarts, Steve Freeman and Nat Pryce.

After the main presentations, we moved into Open Space format. I joined a conversation with John Daniels and Willem van den Ende about "Why Start with End-to-End Tests?". Although we agree whole-heartedly with this, John was interested to explore whether this approach is always a good idea? You can read John's write-up of our conversation on his blog.

John starts by writing this up on the board.

When you start solving a problem from the outside, you ensure that inner workings connect to the real world setting. You start to grapple with all the interfaces to the system from user interface to the back end activities of logging and persistence. An excellent way to flush out any issues that might catch us out and require rework later on.

 
We wonder if the reason working outside-in and creating end-to-end tests is the simplest way to ensure we tackle risks early. John suggests that the biggest risk on some projects could be in the inner logic, for instance if the project was based on running complex calculations. Maybe there are situations where an outside-in approach may not be the best one to take?

Then I rack my brain trying to remember past projects where we didn't start end-to-end. What were the barriers that stopped us doing this?

The first example I remember was back in 1994 when I was working on a broadband switch demonstrator. My company was providing the call-control component but we were working in a consortium where other companies were providing other components that we would interface to, such as a set-top box, etc. Message protocols were not agreed and the hardware was work-in-progress but we had a hard deadline to demonstrate the kit at an industry expo. We did the only thing we could to make headway. We made-up a reasonable message protocol and then worked against software stubs which piped in messages in our imagined protocol. When the real interfaces were revealed, we mapped them into our own internal protocol, on the way in and out. This worked really well for us. We made the trade show deadline. Another example is more recent. A team I am coaching are building on some content-management infrastructure being developed by another department. It's not ready and they've been trying to work out whether to: wait, work on other features, or build their own solution using existing infrastructure.

Realistically, sometimes you need to make a start without having full end-to-end picture.

Our worry is that sometimes teams may prefer the "path of least resistance" because it's easy or they're naive about integration.

However, we ought not to forget that sometimes the biggest risk is organizational politics. It can be important to demonstrate progress to get buy-in from key stakeholders. Scrum can be perfect for mitigating such risks. We work on tangible product backlog items that we can demonstrate every few weeks. This builds trust in the team's ability to deliver on their commitments.

Willem adds that it can be hard for a team to justify "technical" product backlog items that mitigate risk over juicy features with obvious business-value. The team can attempt to make the value of such technical items more obvious by linking them to the money lost in downtime when a site crashes or security is breached.

Another common approach is to pair a Business Product Owner with a Technical Product Owner for projects where there are lots of infrastructure considerations. John pointed out that there's likely to be a tension between long-term technology decisions and short-term project goals. This is where it can help to have a project manager facilitate decision making. Thus, you need a three-way balance (as in this sketch) rather than (as we see too often) the Scrum team kowtowing to Product Owner without speaking up on technical risks.

Perhaps one of the main values of the GOOS approach and working from outside-in guided by tests is that we are able to flush issues out early rather than attempting to anticipate them. Thus we avoid awkward conversations with a Product Owner about potential risks because the issues stare us in the face having driven them out with end-to-end tests.

Comments

[Account Deleted]

Thanks Rachel for bringing up this topic.

When I was doing my little "Avatars of TDD" experiment (http://blogs.agilefaqs.com/2007/12/14/avatars-of-tdd/), 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.

[Philippe Kruchten]

Wouldn't the Technical Product Owner be very close from what other people like me would call the "software architect"? Or as someone suggested to me last week in a workshop in Sydney, the "Architecture Owner".

Note that here is more in software architecture than just infrastructure, though infrastructure plays a big role.

Philippe

[Rachel Davies]

Philippe, yes, I'd say a good candidate for Technical Product Owner would be a software architect (not all organizations have formal role of architect). I'd say a Technical Product Owner might represent infrastructure needs from system admins too.
Rachel