Random Thoughts‎ > ‎

Using models in software development ...

posted Jun 7, 2020, 4:30 AM by Alar Raabe

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 developersdo not want to use the models and therefore making or maintaining these is perceived as "no-value" overhead. Behind thereluctance of developers to use models is often the agile movement's argument that everythingcould be seen/found from the code, and because in DevOps same team that does thedevelopment, does also maintenance, there’s also no need tocommunicate between different teams.

But actually:

  • it is very difficult, if not impossible, to write code so that it all therequirements or high-level design decisions would be presented directly in the code (not to mention being easily readable/understandable for the ones that did not write the code),
  • it costs time and money if developers make mistakes because they are notable to understand from the code the requirements it implements and the design intents/constraints, and
  • it costs even more time and money if developers go away and need to bereplaced by new ones who don’t know anything what has been said "atthe water-cooler" (possibly two years ago).

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 tocollect and maintain this additional information, representing it usually in non-formalizedtextual form in their work-organization tools (e.g. Confluence wiki and in Jira tasks).

Additional reason to dropmodels 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 tobe represented in machine-readable form.

Today still a very big partof the development of business software is solving rather standard/common problems and is filled with the repeatingtasks, 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 ofdevelopment 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 "Dowe want/need to automate also our software developmentactivities?", orwe just want to automate only the various business activities and continue withmanual 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 sameway as for example to automate the credit origination, we need formalrepresentation of customer, loan, collateral, sales process, involved business rules, etc.