Slice By Slice Over Layer By Layer
Assume that your team was tasked with developing a large software system in any application domain of your choice. Also, assume that in order to manage the functional complexity of the system, your team iteratively applied the “separation of concerns” heuristic during the design process and settled on a cleanly layered system as such:
So, how are you gonna manifest your elegant paper design as a working system running on real, tangible hardware? Should you build it from the bottom up like you make a cake, one layer at a time?
Or, should you build it like you eat a cake, one slice at a time?
The problem with growing the system layer-by-layer is that you can end up developing functionality in a lower layer that may not ever be needed in the higher layers (an error of commission). You may also miss coding up some lower layer functionality that is indeed required by higher layers because you didn’t know it was needed during the upfront design phase (an error of omission). By employing the incremental slice-by-slice method, you’ll mitigate these commission/omission errors and you’ll have a partially working system at the end of each development step – instead of waiting until layers 1 and 2 are solid enough to start adding layer 3 domain functionality into the mix.
In the context of organizational growth, Russell Ackoff once stated something like: “it is better to grow horizontally than vertically“. Applying Russ’s wisdom to the growth of a large software system:
It’s better to grow a software system horizontally, one slice at a time, than vertically, one layer at a time.
The above quote is not some profound, original, BD00 quote. It’s been stated over and over again by multitudes of smart people over the years. BD00 just put his own spin on it.
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
Quality Function Deployment QFD ?
That could be one way of defining the content of each slice and determining the ordering of slices. Use cases, user stories, “shalls” may be others.
I think you may have reversed the meaning of horizontal in your last equivocation. I’m not a strong believer in there being extra features in a domain specific API. Some people know more about a domain and will implement more features without being asked to. That it’s not to say that those features are excess because they are not needed for the specific vertical application’s domain. Slice by slice is an addition to horizontal building. Vertical slice by slice is early integration via agile methods where tests and requirements are developed in tandem across layers with domain specific requirements (read business requirements) driving the design and priority of features. IMHO The only thing you have to watch out for its inappropriate developer pushback. Where at any given time in the project one or many developers may be pushing inappropriate feature requests back to another layer to make the development easier or vice versa poorly thought out API that not only don’t provide the data but require extra wrangling to make the API usable. And then there it’s always the over done API or implementation that resists optimization. When it’s clearly doing many things wrong to require that much execution time, memory, disk space, etc. A good rule of thumb for optimization is to find the code that is handling one row at a time when the API let’s multiple rows to be passed in.