Maybe I’m getting old. Maybe I’m even more cynical these days. Maybe I’m just reluctant to change. Take all the above into consideration as I make comment on a ‘new’ phenomenon in my daily working life. Welcome to horizontal slice software development.

Firstly lets take a step back. Way back. For many years the way to make software was separated into ‘blocks’ as in figure 1.

figure 1

Firstly people analysed busyness and designed and documented a computer system to unbusy the busyness. They then passed this documentation on to people who lived in pig pens. These guys created the software application. This was hence sent to a bunch of people who made sure it worked as per the document. Finally once it actually worked we all hung around until the wee hours of the morning while some other guys deployed to production.

Then came a bunch of new-age academic hippie types who, putting down their copy of ‘Wage Labour and Capital’ arose from under a smog of weed smoke with the agile manifesto. Suddenly there was a new way to create software applications where everyone worked together. Rainbows and Unicorns! I’m going to call all this the “Vertical Slice” way of creating software as in figure 2

figure 2

Here small segments of the software application were designed, built, tested and deployed. The deployments were more reliable and slowly new functionality was added and the busy people of the busyness could see all was proceeding well. Some teams designed, built, tested and deployed in time periods called sprints of maybe a week or two, some teams just built, tested and deployed constantly; daily, hourly as and when code was finished as in figure 2.1. And it all worked and functionality was deployed incrementally and it was good.

figure 2.1

Herald the hybrid of the two development methodologies!. I call this the “Horizontal Slice” methodology. Here the busyness decides upon something to be done and it is designed. Actually just the UI is designed. It is designed to look beautiful, wonderful. This UI design is then built, pixel by pixel, and showcased to the busyness. They love it, its shiny and new. They like shiny and new. Once the interface is looking suitably fashionable its time to think about maybe the database design. After some meetings and discussion a schema is finalised and built. Once this is built we start to think about those external actors we need to interact with, hmmm we’ll be needing an api for those, possibly a few… lets get together and have a meeting. So we design and build an API or two so we can talk to the things we need to and they in turn can talk back to us. Then, finally we get to as I like to call it “Switch It On”.  This is figure 3

figure 3

So why does this suck? Well I think the diagram pretty much sums that up.

1. Designing a UI up front. Why? Why would you do that? Designing and developing a UI up front just gives management a false sense of progress, it looks like it all works and it looks good. So ship it already. This means theres pressure, why would you add pressure onto your team for no reason?

UI that links to nothing means theres nothing to test but UI. Which means you get a tsunami of UI defects to fix and no one likes fixing UI bugs. At least not without something else to do to break up the ugly UI bug party you have going on.

Also you spend far too long doing frivolous UI stuff. Don’t get me wrong a sweet smelling UI, buttery smooth sure is a thing to behold. But lets be pragmatic here. Its gotta DO something.

2. API last. The trouble with leaving messaging to last is its not just messaging. Its logging, its performance, its notifying people when things stop working. Its testing it to see what happens when things go wrong and how it reports on the things that go wrong.  It may not be sexy, it may not be beautiful but its way important to your business, way more than that really nice UI warning message for a badly formed email address your team just spent an hour talking about. You know what will happen, you’ll scrimp on the performance testing, scrimp on the logging and scrimp on notifications, and when it does go wrong (as it will) you’ll spend ages trying to work out why.

3. Deploy. Why bother deploying incrementally? Cause for most of the time you just spent developing you’ve made something that doesn’t actually work. That is, something that doesn’t work until the last minute. And you know what that is? Thats waterfall. Thats what that is. You can see that in the diagram, thats the “test all the things work together” bit.