Traditionally one of the most common understandings of what the software engineers do on a development team is that they are individuals that turn caffeine and pizza into code. While this usually gets a giggle or two, it is obviously not the whole picture. The fact of the matter is that when it comes to understanding what developers do, very few people can empathise with the “coders” on a team and the role they play in the development process.
Over many years in various parts of the software industry, I’ve started seeing and appreciating the similarities between the creation of a piece of software and the creation of a piece of art – and to that end, I would like to propose an analogy between the two. I’m a believer that everyone on a software development team is a developer. Whether you test, design or write code, you are part of the development process, and therefore you are a developer. However, for the sake of the analogy, I’ll be referring to the coders or software engineers on the team as developers.
The software development life cycle (SDLC) has many facets to it, but the basic gist of it is that software exists to solve a need a user may have. Most people in the industry would agree that there is a basic flow across all methodologies.
First, the user’s need should be identified. Their need may be based on existing software, it may be a new feature, or it may be a need that they or the world don’t even know they have yet.
Secondly, a solution needs to be designed to meet the user’s need. At this point, there are many people involved, such as the user, some sort of design element and the engineering team. Whether they brainstorm, story map, use design thinking or just chat around a whiteboard; the point is there is a collaborative effort to design a solution to solve the need.
After the solution has been designed, something needs to be built. This leads into some form of engineering phase. This is where the developers code the actual implementation of the solution.
Once the engineering is done, there is a testing phase with a little to and fro with the engineering phase to ensure the solution is viable and works as expected.
After everyone is happy with the testing outcomes the software is handed over to the user.
Most people will agree, that this process is more or less the same irrespective of the methodology you use to support your SDLC. The actual methodology is irrelevant. The intention of this article isn’t necessarily to explain the SDLC, instead, to build an analogy between the engineering phase and the creation of a piece of art.
What makes up art?
Let’s use a painting. Broadly speaking, there is some sort of canvas for the artist to work with. The artist has access to various types of brushes, and is skilled in making use of different strokes and techniques to visualise their envisioned image onto the canvas.
To create the painting, artists mix colours to create new ones, they test different strokes and brushes create different effects to put everything together to create a piece of art. They experiment and explore to get to their final work of art.
Whether it’s spray paint and a wall, watercolours on paper, or oil paint on a cloth; an image is formed for someone else to enjoy.
What makes up software?
Software is very much like an ogre – and no I don’t mean ugly like an ogre. Or at least I hope not! Everyone should be creating beautiful software for your users. But, by now, everyone should know that ogres are like onions. Onions have layers, and just as onions and ogres have layers, software has layers too. There are many aspects to a piece of software over and above what the user sees and experiences. The developers and the architects reading this may argue that it’s not as simple, and they are 100% correct, but this is the crux of what I need for my analogy.
At the top there is a user interface (UI) layer. This is the layer where the user can see information or enter data, and where they touch, slide, click and scroll. Overall it is what the user experiences.
Below the UI layer, there is a layer of logic and processing. This is where the data coming from the user is processed. This layer does the number crunching and deciphers what to feed back to the user. The user interacts with this layer through a user interface. The last layer is where data is persisted for later use.
In these layers, there are many tools. These tools range from the languages we use such as C# or Java, constructs in these languages, and the ifs and loops to help with flow control – algorithms we have learnt. There are all sorts of frameworks, platforms and integrations at our disposal to solve problems and meet the needs of our users. These are very much like our colours, brushes, techniques and canvases all used to form something useful for a user to enjoy.
The engineering
The process until now has been focused on creating something that meets the user’s needs, but the engineering phase is where the developers must solve the problems that were created by the solution. For most people, this part of the lifecycle is a black hole, and this is where I want to pause to connect the analogy to a piece of art. Much like the artists, the engineers need to sit down and use their tools, mix and match, experiment and explore to implement the desired solution.
There is no one way to approach these problems – the possibilities are endless. This is where c creativity needs to flow. To build on to the analogy, each developer (and team for that matter) will also have a unique way of using the tools to come up with a solution.
If you are a developer, you walk out of the story mapping, design thinking session or whichever collaborative exercise your team uses, with a whole cacophony of ideas. While we are one step closer to creating something that meets the users’ needs, we have now just created a whole lot of problems for the engineers.
Our tools may be technical, and our problems may be technical, but we need to get creative when putting it all together in a solution.
As Vasco Duarte said about knowledge work, “It is in doing the work that we discover the work that needs to be done”. Let that sink in for a moment. Even though we already have a solution, there is a whole lot of discovery that needs to take place to turn it into a final software product.
My intent isn’t necessarily to provide a checklist to solve this matter, but rather to create awareness for possible communication barriers within the SDLC that need to be overcome. A great place to start is to visualise. After all, a picture is worth a thousand words.
The intention is, however, to create a bit of empathy for the engineers and what they do after a solution has been designed. At the end of the day, someone needs to solve the problems created by the solution. Thus, my question to you is: “But is it art?”