I see more and more, that the usage of models (referring to traditionally used qualitative, often graphical, models and modeling languages) and model building is diminishing in the software engineering (if we can talk about the software "engineering" anymore at all). The reason seems to be that developers do not want to use the models and therefore making or maintaining these is perceived as "no-value" overhead. Behind the reluctance of developers to use models is often the agile movement's argument that everything could be seen/found from the code, and because in DevOps same team that does the development, does also maintenance, there’s also no need to communicate between different teams. But actually:
Because additional information (same that has been traditionally represented by the models) is needed and because code isn’t usually very much commented and often also not very readable, so often developers and others, involved in the software development activities, try to find other ways to collect and maintain this additional information, representing it usually in non-formalized textual form in their work-organization tools (e.g. Confluence wiki and in Jira tasks). Additional reason to drop models in the software development in favor of informal textual descriptions, seems to be the inability to automate anything in software development process apart from the simple "automation" of build tools to manipulate software artifacts in correct succession (thing that has been around already past 60 years) – so there’s no perceived value to have requirements or high-level abstract knowledge about the software to be represented in machine-readable form. Today still a very big part of the development of business software is solving rather standard/common problems and is filled with the repeating tasks, which are very easily automated (like development of GUIs (where they are not the distinguishing factor), integrations, transformations, reports, etc.), and doing so would economize a lot of development time, but this will be only possible, if the requirements and high-level design would be formally specified and represented in a machine readable form. So, the main question is "Do we want/need to automate also our software development activities?", or we just want to automate only the various business activities and continue with manual software development? If we want to automate software development (i.e. digitalize the software development), we need a formal, machine readable, representation of requirements and high-level designs (with the focus on formalization and machine readability, not just some pictures with "boxes and arrows"), in the same way as for example to automate the credit origination, we need formal representation of customer, loan, collateral, sales process, involved business rules, etc. |
Random Thoughts >