A few days ago, I wrote about my experience delivering a large web project and compared it to the Hertz/Accenture law suit. A friend asked me to go into more detail – here’s the gist of our conversation.

X: isn’t there a risk that by delivering slices, you’ll introduce lots of duplication? If I want to implement a business rule saying “all orders must have a validated shipping address”, and I have two slices – “website user creates order” and “contact centre creates order”, won’t they duplicate that logic?

Sure – that’s a risk. You could well end up with a mess of duplicate code, especially if you have lots of teams working in parallel. There are broadly speaking two ways to mitigate this risk.

The most common is through “architecture” – you agree a software design where there is a single component which manages orders and their business rules. This is perfectly reasonable – but it often comes with some baggage. There is a temptation to design this architecture in great detail, and assign a team to each component. This often means that the component is designed up front, and cannot change in the light of real requirements that are uncovered during development. I’m all for architecture, and I’m all for cleanly defined components which do one thing and do it well. But I believe architecture should be lightweight and focus on principles and infrastructure, and the actual implementation should evolve along with the application.

The second way to avoid duplication is through process and culture – you make sure the teams communicate about their design decisions, and know how and where to look for existing code which is related to their work. You make sure the team has enough time to refactor and extend existing components, and that everybody understands that the team is evolving the architecture together.

X: What about multiple UIs? What if I want to build a platform that supports web, mobile apps, smart TVs, VR glasses?

Sure, another really important consideration. I’ve worked on projects with multiple brands, multiple markets, multiple devices – the possibility for lots of duplication is even bigger. The same answer applies as above, really – yes, a clean architecture is the answer, but no, designing that architecture up front and dedicating a team to the “re-usable” layer is often a bad idea. The user experience on those different devices is often very different, and it’s much better to evolve the re-usable layer as you learn about what you really need than trying to design it in detail up front.

X: And what about skills? Front-end developers want to work with other front-end developers, you get much better code if you have people work together on the same technology layer.

This is indeed a challenge – especially when you have skill requirements you can’t realistically embed in each “slice” team, or where you have particularly complex requirements in one part of the slice. But in my experience, once developers are used to working in cross-functional teams, they really enjoy it – they learn a lot from working with other disciplines. Some of the most useful code review sessions have come from front-end developers and back-end developers looking at each other’s code – they tend to spot mistaken assumptions, rather than stylistic problems.

I don’t think there’s a nice structural solution to this question – a neat org chart you can draw showing how teams work. I think the solution lies in culture, rather than structure – coding in the open, joint ownership, a shared understanding of “what the project is about”.

X: OK, but how big should a “slice” be?

Good question. As usual, it depends.

The key goal of “slices” is to make sure everyone – developers, business sponsors, QA, designers – has the same perspective on “what the project is”, and “how much is done”. So a slice needs to be demonstrable to business people, in a way that clearly communicates what works and what doesn’t. It needs to have a user interface (even if most of it is placeholder), and it needs to push logic all the way down the stack.

But it doesn’t need to scale, or be fast, or be pretty. It can have some technical debt, and it can cover only the “happy” path. It might only work for one of the different types of users, or one type of content, or one workflow.

X: I think I understand. What do I do after my first slice?

Another good question. I like to structure projects so that we build the first slice as quickly as possible (4 weeks or so is great); I typically ask the entire team to focus on this goal. Once the first slice is delivered, I like to add more slices every 2 weeks. At this point, it may make sense to have some of the team working on cross-cutting concerns (build/deployment, shared look & feel, etc.). It may also make sense to build larger components outside a slice – some things just take more than 2 weeks to deliver. However, I try to keep at least half the team working on the “slice”.

Updated: