CodeBork | Tales from the Codeface
The coding blog of Alastair Smith, a software developer based in Cambridge, UK. Interested in DevOps, Azure, Kubernetes, .NET Core, and VueJS.
Project maintained by Hosted on GitHub Pages — Theme by mattgraham
Before Christmas I was talking with Simon about an architectural approach we’d taken on a recent project. The aim of the project is to replace an existing WinForms user interface with a shiny new HTML and JavaScript version. Part of this involves making HTTP requests back to the “engine” of the product, a .NET application, and of course our chosen data format is JSON. To protect the HTML UI from changes made in the Engine, we decided to keep a separation between the models we transferred over HTTP (what we termed Data Models), and the models we used in the application (or, “Application Models”). The approach that we took had similarities with the concept of Desire Lines from landscape architecture, as described in Practices for Scaling Lean and Agile Development by Larman and Vodde. A desire line (or desire path) is a path that evolves over time, as a result of people walking or cycling from where they are to where they want to be, and usually represents the shortest (or easiest) route between those points. These desire paths provide a key indication of the routes people take to reach a destination, and many desire paths become fully managed “official” paths, upgraded to gravel or tarmac. A good example from Cambridge is the green open space called Parker’s Piece*. Bounded on all sides by roads, it has two main paths, running roughly North-South and East-West†:
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”