Thursday 15 September 2022
Where do technologies fit in to automate development and assist the developer?
How is software produced and operated in practice?
Low-Code and No-Code tools (e.g. Appinventor  , Budibase  , WebRatio  , Figma  , Debuild , etc.) allow us to automate development following a user-centered design approach (they use user-friendly graphical interfaces and configurations to create solutions) . In addition, there are AI technology tools (e.g. GitHub copilot  o OpenAI  based on GPT3) that can be used as an assistant in design and code development tasks. In the following, to better understand the implications these technologies could have on software production and operations, we will see how software projects are carried out in practice and why it is becoming more and more powerful for us to follow a user-driven design approach in contrast to the classical development lifecycle we all know (regardless of whether we do it in a waterfall or iterative-incremental way).
Anyone who has faced the design and development of a software product, and even more so if the project is an R&D project, knows the initial uncertainty that these projects have. The design and development of prototypes allow us to acquire knowledge more quickly about the solution that is needed with little effort. In addition, any change in the exterior design of a product (its interfaces) will affect the interior design of the product, so it does not seem to make much sense for us to design its interior before we are sure that its exterior design will not change (or will change little). Once we are sure that the exterior is "more stable", we can systematically design and build it to be "useful", but always, keeping in mind that we will offer a service and that we must ensure certain "guarantees". The usefulness of the artifact is what would be mainly related to the functional requirements of the product, while the guarantee (security, capacity, availability, continuity, etc.) would be more related to what we call non-functional requirements. In the end, requirements are present throughout the product life cycle, as shown in Figure 1.
Figura 1. How requirements are related in the product lifecycle (source: own elaboration)
What strategies can we infer from practical experience as a strategy for software production/operations?
• Development: The goal is to build as systematically as possible (it is not science; it is engineering). It is achieved by obtaining software that is "useful" for its users and that has been tested in a development environment. It is an activity where software is generated.
• Operations: The objective is to make the software available to users so that they can carry out their activities. This is achieved through the implementation of a service that allows users to use the software with "guarantees".
Design and Build activities would similarly be separated into two activities: (Discovery) those activities that aim to design and build a small technical demo and (Development) those activities that aim to design and build the software.
Testing (and we can include continuous monitoring if we include operations), would be separated into three: (Discovery) system tests that can be defined using prototypes to "validate" the software by means of a disposable prototype, (Development) unit and integration tests that allow us to "verify" the software, and finally (Operations) continuous monitoring that allows us, in real time, to control and track the service we are offering.
Discovery/Research, Development and Operations (Learn2Build vs Build2Learn)
Figure 3. Discovery, Development & Operations.
The Learn2Build approach allows learning to be enhanced prior to construction. It is useful when we find ourselves in a context with high business and technical uncertainty. In other words, we are not clear about what the problem is, what we have to build nor how we are going to build it. A strategy that would fit in this approach would be a Design Thinking process or the Design Sprint methodology. . The SAPIENS methods that we will see in the following would also fit in. The validation of the artefact (at least about its usefulness, not its guarantee) in very early stages allows us to reduce the efforts and the cost involved in finding possible competitive advantages (which we will see later and which is a concept related to innovation).
2. If we also integrate “Operations" where deployment is carried out in both pre-production and real production environments, allowing users to use the software under guaranteed use.
Figura 5. Build2Learn aproach.
With all of the above, the important thing is that we have a team that, at any given time, adapts to the circumstances according to the context as shown in Figure 6, where at a given time we could start by applying only a Learn2Build approach (Discovery), at another time we could combine both approaches but without deploying in production (Discovery & Development), or only apply a Build2Learn approach deploying in production environments (Development & Operations).
It is also important that a systemic execution of the process is carried out, as opposed to an improvised execution. The main difference is that we have clear our strategy (what processes and stages of the above we carry out) and our tactics (what methods, techniques, and software artefacts we use in those processes). Regarding the latter, I leave you with a phrase from Sun Tzu's book "The Art of War" that gives rise to reflection on strategy and tactics in software engineering: "Strategy without tactics is the slowest road to victory, Tactics without strategy is the noise before defeat".