Even the briefest of glances at that deliberately rough sketch map provides a clear idea of where the points of interest lie outside of Parker’s Piece. In the top corners, we have obstacles – to the left, the public toilets; to the right, the University Arms hotel – and in the bottom left corner, we have objects of desire: the gym and swimming pool, a skate park, and a pedestrian crossing. I find it interesting that not only do desire paths represent the shortest or easiest path to an object of desire, but that they also represent the shortest path around an obstacle.
Ok, ok, but how does this apply to software architecture?
Well, the overall concept of desire lines has similarities with both the “outside-in” development approach described by books such as Growing Object-Oriented Software, Guided by Tests and the Lean and Agile principles of a minimum viable product (MVP) and incremental development. The MVP can be considered the diagonal paths in the sketch above, the basic routes from one side of the grass to the other; the desire lines represent the incremental development, added as and when they become needed – for example, I gather the skate park didn’t exist in the 16th century when Parker’s Piece was first established!
A more concrete example is in communication between disparate systems. Remember in the opening paragraph, I mentioned the HTML UI communicates with the product’s engine via JSON? In this sort of scenario, you can start with a minimum viable data contract and add to it as more of the application is built. Or to put it another way, working from the outside in, you let the consumer define the data format and, as you build this consumer, so you build the data format (this applies to behaviour as much as data, of course, but that’s another blog post.) Taking the ubiquitous to-do list app example, you might build up your data contract as follows:
An alternative approach, which we took on this project for reasons of practicality, is to provide a very loose data contract and then refine it as you build. This roughly translates to throwing everything and the kitchen sink over the wire for every request, and then refactoring the data contracts as you build the client. We took this approach in our project because the HTTP endpoints were developed independently of the user interface up front, and that team didn’t know at the time what the UI would need. They developed a proof-of-concept UI along the way which consumed this data, and the production-quality UI is refactoring those data contracts along the way. In honesty, I wouldn’t recommend taking this approach unless your hands are tied, as it’s analogous to refactoring a God Object. To stretch the desire lines metaphor to the point of breaking, it’s a bit like covering the proposed green space with gravel and grass seed, and letting the grass grow through the gravel where people don’t walk, then scooping up the gravel in those areas and properly turfing them. Basically, a massive faff, and one that is likely to produce less well-defined results than the true desire lines approach.
I’ve had a few musings around the MVP concept over the last few weeks, and this latest addition was sufficiently interesting to share. Certainly I will be keeping it in mind in the coming weeks and months as we start on new development work.
*Factoid: Parker’s Piece is considered the birthplace of the rules of Association Football!
†The elaborate lamppost at the crossing in the middle is known as “the Reality Checkpoint”