Vertical Slicing

Delivering working software in the hands of the customer is one of the core principles behind agile software development, and one that we follow at Webjet. This means teams break down their work into bite sized chunks and deliver working chunks iteratively.

But back when we started our agile journey, this usually meant working on the back end, followed by working on the front end. As you might have guessed it the “working software” was only delivered at or close to the very end. Not ideal.

I didn’t know the word for it at the time, but we were doing Horizontal Slicing, i.e. breaking down work based on its functional area, without taking a holistic end to end approach. We were iteratively delivering a car by delivering only the wheels first.


Going back to the core principles, we looked at how we can deliver a true MVP, something that provides value to the customer and to the company, something that we are happy to have in production. We came across the concept of vertical slicing, which helped us articulate the MVP approach.

Vertical and Horizontal Slicing

Using the example of creating a new flight search experience for mobile browsers, I will share our thinking and how we approached vertical slicing, which will help crystalize the concept

Our flight search experience for mobile needed an update. The incumbent design was a copy of the legacy app experience, built using JQuery mobile integrated into our monolith. This made making changes more complicated and take longer to deliver. It was not aligned with our strategy of splitting it into independently deployable microservices.

Old Mobile Search

We decided to create a new React based service to render the responsive front end coupled with a new search API. This would make iterative changes less complex and faster to market. But there were a lot of features to deliver, multiple result views, and the integration with the legacy platform.

New Mobile Search

To help define the workflow the team documented the high level workflow

High level workflow for mobile Flight Search

To help guide our decision in defining the MVP we looked at the following

  • Data on the booking mix i.e. domestic vs Trans-Tasman vs international, one-way vs return, passenger mix etc
  • Key path dependencies
  • An MVP that delivers value to the customer

The following were the results of the analysis

  • A large majority of the bookings were domestic, so the real value from a customer’s POV lay there
  • As domestic volume was higher any issues in the new path could be amplified
  • A wide range of passenger mixes existed, e.g. 1 adult, 2 adult and 1 child, 2 adults etc
  • Integrating into the legacy shopping cart was a key dependency. Until now the search and booking happened in the same platform.
  • The incumbent mobile design was quite dated and had limited functionality. Customers could only sort on 4 attributes and there was no filtering

Based on this we determined the first slice as a

  1. Single one-way adult search: limits the scope of the customer cohort
  2. For a medium capacity route: reduces the risk of unexpected failures and provides value to the customer
  3. With just the sort functionality currently supported: limits the feature set that needs to be built
  4. That can be searched and booked end to end: reduces key path dependency

MVP identified in Mobile Flight Search

The team went on to develop this MVP and release it to the customers in a fraction of the time of the full design build. After based on feedback from data gathered, we iteratively added more features starting with supporting return search and result filtering. The team could quickly support more routes and passenger mixes using feature flags as their confidence grew in the new services.

Not only were we able to deliver value iteratively, but since we only focused on a narrow path it gave other advantages

  • Validation of the new design in the hands of the customers
  • The team did not need to develop a Trans-Tasman or an international design till much later
  • Increased confidence in monitoring and alerting of the service as the load slowly increase

Looking back at our approach the key element that made this a success was a strong engagement with the business stake holders. Having their input and buy in to delivering a fraction of the promised functionality in the customer’s hands was crucial. We used real metrics to measure customer satisfaction with our new design. It also helped us tweak features that were causing issues and iterate on the features that were well received.

Without it we would be relegated to releasing in our UAT environment which would not give true confidence in the design, and customer would have waited months to get any value.

If you are interested in joining our team, we are hiring!
Our current job postings can be found here:

Blockchain: The Silver bullet?


If you’ve read the news Blockchains are going to be everywhere, revolutionizing all industries as they go along.

But what is it really?

A blockchain is essentially an immutable distributed database. This database is shared but all parties on the network, each having their own copy, and each able to inspect it. All participants can add data and query the database, but none can change its previous state (like delete a previous entry). In our view its better to visualise it as a distributed ledger, say a land registry, rather than database.


This basically means that once some data has been added to the block chain it can never be removed. carrying on with the land registry, example, one can’t erase a record, even if its an error. A new entry has to be added that updates the previous entry.

There are lots of resources on the web that go into great detail explaining how the immutability is achieved, but at a high level the participants of the network enable this. For any one participant to alter the chain, it needs to convince at least 50% of the other participants to accept its version of the chain.


Blockchain became popular with the size of Bitcoin, where the concept of an immutable distributed ledger enables Bitcoin to function without any central authority.

This early implementation of blockchain can be referred to as blockchain 1.0. What has got everyone really excited is Blockchain 2.0, which introduces the concept of smart contract. A smart contract is essentially computer code that is compiled and stored on the block chain. Users can then updated its data (variables) when interacting with it. Since the Blockchain ensures immutability, we can be assured that no one will alter the code or values (without leaving a paper tail).

Using this concept we can code up real world contracts between one or more parties in code, that can mimic, say what happens in a supply chain. In a traditional supply chain we have a long list of suppliers and consumers, e.g. iron ore manufacturer -> Iron manufacturer -> steel sheet maker -> automobile body builder and so on. This leads to inefficiencies as currently tracking the goods and the amounts owing would be maintained by each party in generally their own supply chain and billing management system. There is also no one version of the truth, and when things don’t match manual reconciliation needs to take place.

Using smart conracts all participants, from the iron ore producer to the car manufacturer can enter into a smart contract, that tracks the good from the point of origin to the eventual destination. Along with it ti can also tract and trigger payments (via a virtual crypto currency like Bitcoin) automatically at the agreed times.

But it’s not all rosy. There are still many issues to be solved. If you read the news recently, ehterum (a public Blockchain 2.0 provider) was hacked, due to known bug in the execution engine that the smart contract programmer had not handled correctly. This led to millions of dollars of funds vanishing. This is something that the industry will be watching very closely.

Also there are real use cases when the contract needs to obtain information from an off chain system, e.g. a stock ticker, or a time provider, to execute some transaction. Microsoft recently announced Project Bletchley, which is touted as Blockchain 3.0. This seems to offer an answer to this problem by provided a secure way for Blockchain to interact with off chain system.

The ASX recently announced that they are experimenting with Blockchains as a means for faster stock trading reconciliations. It’s still early days yet but advancements in Blockchain could really change the way we do business especially in the financial sector.

World peace, well that may have to wait till 4.0