Software development is a process that undergoes repeated cycles of transforming business ideas into code via intermediaries such as product requirements and technical designs. This chain reaction is realised and supported by humans who usually take up one of the following broad roles: product owner, business analyst, architect or developer. Each of these roles corresponds to a step in a cycle: the product owner is responsible for gathering and communicating business ideas, the business analyst creates a set of product requirements out of these, the software architect draws out a technical design and, finally, the developer implements these into a working piece of code. This should be uncontroversial, it’s a general pattern observable in most contemporary software companies. In this article, I introduce a latent dimension connecting these flows, which, once seen, can’t be unseen and should help any member of a software development team to understand better what’s really going on and thus communicate and cooperate better. A software development cycle is characterized by an incremental increase in rigour during each step. That is, the language that is used to describe and ultimate solve the problem at hand becomes progressively more structured. I call this the formalisation flow of software development. When a product owner communicates their business ideas, natural language is the medium. The business analyst’s product requirements tailor down this communication to several individually verifiable conditions which capture the business’ intent. Next, the software architects, aware of the codebase, transforms these requirements into a diagrams, tables and flowcharts describing how larger bits and bobs connect to meet these conditions within the software product. Lastly, the software developer implements the designs to meet the requirements and ultimately deliver the business value sought after. Each stage thus introduces more formalisation, i.e. imposes a higher number of syntactic constraints on the materialisation of the business ideas. This is a difficult process and the margin of error gets increasingly smaller. Though, the further in the process, the more preparatory work one can rely on (if execution happens from left to right). The nature of computers necessitates an end-product that’s somewhat formal (yes there are different levels of abstraction available in the choice of programming language but binary machine code is still the what runs through the CPU), so the last step of the flow can’t really be argued with. Businesses can only exist when there are people grouping together to make ideas into something operational, so the first step of the flow can’t go either. The steps in between are up for grabs but do exist ultimately to accommodate a smoother transition from ideas to code. How can knowledge of this hidden dimension help a member of a software development team on a day-to-day basis? The biggest take-home message is that, ultimately, each member is working on the same task: the materialisation of business ideas. They’re just all doing it at a different level of formalisation. This means that each link in the chain can obtain useful information from any other link in the chain. But equally, each link can communicate useful information to any other link in the chain. So, the flow isn’t really a linear flow. It’s a bidirectional complete graph where information flows through. A software developer isn’t just an automaton implementing the instructions received from an earlier link in the chain. In fact, they have the most complete specification of the business at hand, i.e the code. In other words, a software developer might as well know as much about the business operations as any other node in the network. An excellent illustration of such a case is exposed by Elon Musk (see video below, around minute 20), who found out that twitter operated a blocklist for accounts that would never be shown as trending. This was a business operation hidden in the minds of a select few and those having knowledge of that specific piece of code. Likewise, a business analyst might gather information from both the product owner side and the software architects / developers side. https://www.youtube.com/watch?v=pjc_oo4ApSY&embedable=true Each actor in this software development process gains a personal advantage when they are comfortable at more than one level of formalisation and have good relationships with other links in the chain / nodes in the network. All nodes are equal but some are more equal than others, know your worth. Software development is a process that undergoes repeated cycles of transforming business ideas into code via intermediaries such as product requirements and technical designs. This chain reaction is realised and supported by humans who usually take up one of the following broad roles: product owner, business analyst, architect or developer. Each of these roles corresponds to a step in a cycle: the product owner is responsible for gathering and communicating business ideas, the business analyst creates a set of product requirements out of these, the software architect draws out a technical design and, finally, the developer implements these into a working piece of code. This should be uncontroversial, it’s a general pattern observable in most contemporary software companies. In this article, I introduce a latent dimension connecting these flows, which, once seen, can’t be unseen and should help any member of a software development team to understand better what’s really going on and thus communicate and cooperate better. A software development cycle is characterized by an incremental increase in rigour during each step. That is, the language that is used to describe and ultimate solve the problem at hand becomes progressively more structured. I call this the formalisation flow of software development. When a product owner communicates their business ideas, natural language is the medium. The business analyst’s product requirements tailor down this communication to several individually verifiable conditions which capture the business’ intent. Next, the software architects, aware of the codebase, transforms these requirements into a diagrams, tables and flowcharts describing how larger bits and bobs connect to meet these conditions within the software product. Lastly, the software developer implements the designs to meet the requirements and ultimately deliver the business value sought after. Each stage thus introduces more formalisation, i.e. imposes a higher number of syntactic constraints on the materialisation of the business ideas. This is a difficult process and the margin of error gets increasingly smaller. Though, the further in the process, the more preparatory work one can rely on (if execution happens from left to right). The nature of computers necessitates an end-product that’s somewhat formal (yes there are different levels of abstraction available in the choice of programming language but binary machine code is still the what runs through the CPU), so the last step of the flow can’t really be argued with. Businesses can only exist when there are people grouping together to make ideas into something operational, so the first step of the flow can’t go either. The steps in between are up for grabs but do exist ultimately to accommodate a smoother transition from ideas to code. How can knowledge of this hidden dimension help a member of a software development team on a day-to-day basis? The biggest take-home message is that, ultimately, each member is working on the same task: the materialisation of business ideas. They’re just all doing it at a different level of formalisation. This means that each link in the chain can obtain useful information from any other link in the chain. But equally, each link can communicate useful information to any other link in the chain. So, the flow isn’t really a linear flow. It’s a bidirectional complete graph where information flows through. A software developer isn’t just an automaton implementing the instructions received from an earlier link in the chain. In fact, they have the most complete specification of the business at hand, i.e the code. In other words, a software developer might as well know as much about the business operations as any other node in the network. An excellent illustration of such a case is exposed by Elon Musk (see video below, around minute 20), who found out that twitter operated a blocklist for accounts that would never be shown as trending. This was a business operation hidden in the minds of a select few and those having knowledge of that specific piece of code. Likewise, a business analyst might gather information from both the product owner side and the software architects / developers side. https://www.youtube.com/watch?v=pjc_oo4ApSY&embedable=true https://www.youtube.com/watch?v=pjc_oo4ApSY&embedable=true Each actor in this software development process gains a personal advantage when they are comfortable at more than one level of formalisation and have good relationships with other links in the chain / nodes in the network. All nodes are equal but some are more equal than others, know your worth.
