Go Deep Rather than Wide

When defining, building, and testing a system, we can go deep or wide. Deep means taking a vertical slice that provides functionality across layers of a system, end to end, which enables a feature. For example, we may enable a user to log in, which would include the client-side UI all the way to the server storage. Wide means building out each layer first before wiring them together so all the services in a layer would be built out together.

Whenever possible, go deep rather than wide. When building a product, build out functionality through features rather than in layers and avoid anything that delays having running code. When you build deep you are always creating needed behavior and building it the way those behaviors will be used. This is far more efficient than creating libraries of features that can be called from different layers in a system.

I resisted this idea for a long time, convinced that careful planning and segmentation of work could help us deliver more value faster but it turns out that in most cases building the most valuable features first is the best place to start.

Being feature-driven doesn't preclude the emergence of an architecture, but that architecture comes about organically over time, and tends to be more resilient than ones that were created at the beginning of a project. Just as it's far easier to edit written text than to start with an empty page, it's easier to start with a working system and refactor it to improve the design and make it more supportable.

Going deep focuses development on features the way they'll be used in production. This helps pieces of code fit together more easily and provides working features faster than building a library of services that will eventually be consumed.