The triangle of software development

The Iron Triangle could easily have been something from Game of Thrones, but I'm talking about the classic project management version in this case. As a quick recap, it's stating that work's quality is constrained by budget, scope and time. And the role of a project manager is to manage trade offs between those, knowing that one of the parameters will necessarily need to be offset by the others. So for instance delivering the same scope with the same quality in less time means increasing budget. Part of this philosophy is how you end up with the belief that 9 women can deliver a baby in 1 month, to quote a classic from software management.

In this post I would like to discuss a different triangle that is perhaps a bit better suited for looking at the quality of products and how leadership teams can drive focus to influence the outcome. Introducing: Form - Function - Execution.

Let's dive into each of those areas for a second.

Function- Define the “what”

Function is typically the domain of product teams. This is very much around defining the "what" of a product. How you arrive at defining that "what" is a little outside the scope here and there are many well known techniques, from lean startup style early testing of assumptions to google design sprints and extensive long-duration user research, to name a few. At a macro level, the goal of this part of the triangle is to answer the question of how this product solves a problem for the target audience, i.e. "what does it do".

Form- Design and visualize the what

Form is predominantly the world of creative teams, and I take creative teams in a rather broad sense. It's the obvious visual elements but also the user experience, interaction design and copywriting. While form has value in it's own right, it's of course also there to support the user in discovering and use the functionality. There is a lot of literature and debate around form vs function (or form follows function if you're into industrial design) but the main point is that there is a clear trade-off between these which needs to be considered.

Execution- From what to how and deliver

The last component is execution or, when talking about software, the large set of activities that take input from product & design and produce the tangible version for people to use. While they're not necessarily at the coalface in defining either form or function, by nature of actually building the end product they're very much making the ultimate decision on what your product looks and feels like. In reality those decisions are potentially more like death by a thousand cuts and happen without real need for debate (nor would that be practical), but they shape your product as much as either those involved directly in form or function.

Bringing it all together

Of course these 3 components don't operate in isolation. To deliver a quality product you need to strike a balance between them. If one gets too dominant you end up with good looking functional products that fall apart when you touch them; shiny solid products that don't solve a problem; or something that is visually very hard on the eyes but extremely functional and well built, like my favourite text editor: Vim. If you're managing an organisation the goal is to manage the relation between these three and of course put your own accents to arrive at a product. For instance Apple is a classic case of a company who puts the strategic focus more on form and function rather than execution. Google on the other hand is a lot more in the execution and function areas rather than form. They're of course not ignoring any of the 3 pillars, but it's clear how giving a little more weight can create very different results.