Where do the technologies to automate development and assist the developers fit in?
How is software produced and operated in practice?
The tools Low Code and No Code (e. g. Appinventor [4] , Budibase [5] , WebRatio [3] , Figma [6] , Debuild [7], etc.) allow us to automate the development following a design focus centered in the final user (they use graphical interfaces and user-friendly configurations to create solutions) [1][2]. In addition, there are AI technological tools (e. g. GitHub copilot [8] or OpenAI [9] based in GPT3) which can be used as an assistant in code design and development tasks. Furthermore, 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 increasingly more important that we follow a user-oriented design approach in contrast to the classic development life cycle that we all know (regardless of whether we cascade or iterative-incrementally).
Anyone who has faced the design and development of a software product, and even more so if the project is R+D, knows of the initial uncertainty that these projects have. The design and development of prototypes, allows that with little effort, we can acquire knowledge more quickly about the solution that is needed. In addition, any changes in the exterior design of a product (its interfaces) will affect the interior design of the product, so it does not make much sense for us to design its interior before making sure that its exterior design will not change (or change little). Once we are sure that the exterior is “more stable”, we can design and build it systematically so that it is “useful” but always taking into account that we will offer a service and that we must ensure certain “guarantees”. The usefulness of the device is what would be mainly related to the functional requirements of the product while the guarantee (safety, capacity, availability, continuity, etc.) would be more related to what we call non-functional requirements. In the end, the requirements are present throughout the life cycle of the product, as shown in Figure 1.
As we mentioned, regardless of the development cycle we follow (e.g. broken or iterative-incremental), traditionally the classical stages of software development, without entering into operations, are: Requirements elicitation, Requirements analysis, Design, Construction/Implementation, Testing. In fact, the previous stages are those that appear in the ministry templates that we use as auditors to evaluate the projects carried out in our country to qualify a project as “technological innovation” or “R+D”. In these 3-4 years as an evaluator, I have been able to evaluate more than 50 projects of this type. Briefly, some of the issues I’ve noticed are:
• The concept of “Requirements elicitation” is mixed “Requirements analysis”. Elicitation should only cover the understanding and definition of the problem (e.g. a business model describing the current reality, just to understand needs), whereas in the analysis, the solution should be approached independently of the technology (e.g. interfaces, class diagram, case diagram, activity diagram, sequence diagram, etc.).
• The concept of “Requirements Analysis” is mixed with “Design”. While the analysis is generic, the design is specific to the platform or technology used to build the solution. In most of the projects evaluated, the Design includes analysis diagrams (that is, generic, without specifying any technology).
• Technical documentation does not usually follow any reference model, standard or normative (e.g. UML or BPMN techniques). In this sense, it would be important to standardize a minimum of technical documentation for this type of project (which I am sure would be appreciated by all those who evaluate this type of project).
• When tests are included, they are usually low quality ones. Only verification activities are appreciated (past, after designing and building, making sure we have designed and built the right solution), with few validation activities (future, before designing and building, making sure the solution is the right one). There are also no mention of continuous monitoring activities (present, make sure the software works in real time) [10].
• In some cases, the screens that are provided sometimes you do not know if they are prototypes or real screenshots of the developed software. However, code excerpts are often solicited as evidence that development took place.
What strategies can we infer from practical experience as a strategy for production/software operations?
If we make the effort to transfer all these activities to a model like the one in the figure above, we would have something like the one shown in Figure 2. In the following figure, a complete life cycle of the software product has been considered, from its conception (Discovery), followed by its design and development (Development), to its production as a service (Operations).
In a very brief way, the objectives and the main activities would be the following:
• Discovery: The goal is to learn as soon as possible about the problem and the solution, reduce technical and business uncertainty. It is achieved through the construction and validation of a single-use prototype (business) and small technique demos to help us make decisions about the technological components that we will use in construction. It is an activity of research and generation of knowledge.
• Development: The goal is to make construction as systematic as possible (it’s not science, it’s engineering). It is achieved by obtaining software that is “useful” for its users and 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 by launching a service that allows users to use the software with “guarantees”.
If we move the activities from a classic development cycle to this product life cycle, we will realize that it does not only cover Development. For example, the elicitation of requirements, would fit into the understanding and definition of the problem. The Requirements Analysis activity would be separated into two activities: (Discovery) those that affect the external definition of the solution (interfaces or prototyping) and (Development) those related to the internal definition of the solution (class diagram, sequence diagrams, etc.).
The Design and Construction activities, in the same way, would 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.
The testing activity (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 using a single-use prototype, (Development) unit and integration tests that allow us to “verify” the software and finally (Operations) continuous monitoring that allows us, In real time, control and track the service we are offering.
Discovery/Research, Development and Operations (Learn2Build vs Build2Learn)
Depending on our context, there could be different situations that would imply that we can focus more on Discovery (for example, applying a Design Thinking process), or on Development and Operations (for example, applying the set of good practices of DevOps).
The Learn2Build approach enhances learning 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 sure what the problem is, what we need to build, or how we are going to build it. One strategy that would fit this approach would be a Design Thinking process or the Design Sprint methodology [12]. The SAPIENS methods that we will see below would also fit in that description. The validation of the device (at least on its usefulness, not its guarantee) in very early stages allows us to reduce the efforts and cost involved in finding possible competitive advantages (which we will see later and which is a concept related to innovation).
On the other hand, the Build2Learn approach allows enhancing the obtaining of functional products that provide real value to the user[11][13] In this regard, the definition of value is very important, and here we should differentiate the “Value” that is provided:
1. If we only address a “Development” where the deployment takes place only in a development environment and the user still cannot take advantage of the software from which it is contributed.
2. If we also integrate the “Operations” where the deployment is carried out both in pre-production environments and in real production environments, allowing users to use the software under guarantees of use.
In addition, this approach requires that we have a technically very mature team, since the cost of designing and building software solutions must be very similar to the design and construction of a disposable prototype. Moreover, it may also require the application of minimal discovery and requirements management strategies (e. g. Llegeixin Inception [14] or Agile Inception), since it is very important that good planning is carried out to prioritize those functional characteristics (utility) and non-functional (guarantees) that we anticipate would add more value to the business.
Following all the above, it is very important that we have a team that, at all times, adapts to the circumstances according to the context as shown in Figure 6, where at a certain time we could start applying only a Learn2Build approach (Discovery), at another time combine both approaches but without deployment in production (Discovery & Development), or, only apply a Build2Learn approach deploying in production environments (Development & Operations).
Furthermore, it is important that a systemic execution of the process is carried out, as opposed to what would be an improvised execution. The main difference is that we are clear about our strategy (what processes and stages of the previous ones we carry out) and our tactics (what methods, techniques and software artifacts you use in these processes). On the latter, I leave you a sentence from the Book “The Art of War” by Sun Tzu that gives rise to reflection on strategy and tactics in software engineering: “Strategy without tactics is the slowest path to victory, Tactics without strategy are the noise before defeat”.
Management and continuous improvement
Being aware of the different contexts and strategies where different strategies can be applied, the most important thing is that the organization carries out these practices in the most systematic way possible, and not work in an improvised way.
On the other hand, this systemic process (we do the same, we obtain similar results), also allows us to identify whether a certain change in our strategies and tactics (for example, using a new tool instead of another) allows us to improve or not. The following figure shows the strategy that any management process would follow. Any of the approaches we saw above that combine Learn2Build and Build2Learn approaches would fit into the “Execution” of the management process. Improving our effectiveness would imply meeting our objectives (e.g. meeting the planned scope) while improving our efficiency would involve making some change in our strategy that would improve our execution (for example, we meet objectives with lower cost in time or resources).
Conclusions
Finally, we will conclude with the most relevant conclusions:
• Different contexts (problems) require different strategies (solutions). Consider a strategy that takes into account the life cycle of the product (not only development):
- Discovery, Development, Operations
- 2 context-based approaches (technical and business uncertainty): Learn2Build vs Build2Learn
• About management and continuous improvement
- It is important that the organization carries out its strategy in the most systematic way possible (never in an improvised way).
- Improving our effectiveness would imply meeting our objectives while improving our efficiency would involve making some change in our strategy that would improve our execution.
REFERENCES
[1]. El País, “Low Code cómo aparender a programar sin saber programar”, accesible online: https://elpais.com/tecnologia/2022-05-06/low-code-como-aprender-a-programar-sin-saber-programar.html, últim accès: Juliol 2022
[3]. WebRatio, accessible online: https://www.webratio.com/site/content/es/plataforma-de-desarrollo, últim accès: Juliol 2022
[4]. MIT Appinventor, accesible online: https://appinventor.mit.edu, últim accès: Juliol 2022
[5]. BuidBase, accesible online: https://budibase.com, últim accès: Juliol 2022
[6]. Figma, accesible online: https://www.figma.com/, últim accès: Juliol 2022
[7]. Debuild, accessible online: https://debuild.app/, últim accès: Juliol 2022
[8]. GitHub copilot, accesible online: https://github.com/features/copilot, últim accès: Juliol 2022
[9]. OpenAI examples, accesible online: https://beta.openai.com/examples/, últim accès: Juliol 2022
[10]. Morales-Trujillo et al. “A Testability and Observability Framework to Assure Traceability Requirements on System of Systems.” Journal of Web Engineering (2020): 297-318.
[11]. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, LLC. Print ISBN:978-1942788003.
[12]. Jake Knapp, J. Z. (15 de 12 de 2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. First Simon & Schuster. ISBN 978-1-5011-2174-6. Obtained from http://www.gv.com/sprint/
[13]. Forsgren, N., Humble, J., & Kim, G. (2018). The Science of Lean Software and DevOps. ACCELERATE. Building and Scaling High Performing Technology Organizations. IT REVOLUTION. ISBN:9781942788331.
[14]. Paulo Caroli (2019), Lean Inception: How to Align People and Build the Right Product, ISBN 10: 8594377134.