I predict that in just one year the state of Model-Based Design could (1) see a jump equivalent to 7 years of normal progress; COVID-19 has brought to the forefront a needed set of transformations that will reshape the processes and infrastructure that define Model-Based Design. It gives us an opportunity to realize a new vision both for these times and beyond.
In a painting, every brush stroke(2) matters; but it is only in the collection of the strokes that the full image is revealed. Fortunately, in the software development process, you do not need all of the “strokes” to see the full picture; each improvement stroke provides a return on investment. By intelligently clustering the strokes together you see a multiplicative effect.
The objective of this new series of blogs is to provide the strokes and to define the clusters so the order of adoption can be optimized.
The obvious change due to COVID-19 is working remotely; this change exposes multiple areas where Model-Based Design should be improved. Cultural needs feed into process changes, which then mandate enhanced automation; these are the “strokes” that we will look at.
The clusters
I want to introduce a few of the clusters I have already identified as “ready” for transformation. As this blog continues, this list will be expanded and refined. For now…
The review process
Current review process depend on two things, informal communication before the actual review and the highly interactive nature of in person reviews; both of these suffer in the remote working environment. To create a better review process there are several “strokes” that are needed. Changes in Architectural style to make review easier, up-front communication through the use of ICDs, and automation to validate prior to the meeting.
Creation and validation of physical models
At first glance, the creation of physical models should not be impacted by COVID-19. If we are building our models from first principles then those principles are the same if we are in the same room or not (3). However, in practice, first principle models are not practical and simplifying assumptions need to be made, which in turn means that the model needs to be validated against real world data(4). How do you collect that data when you need to social distance? How do you validate it?
Requirements life cycle
The requirements life cycle will perhaps see the most important changes. Requirements act as the primary source of truth in the development process; as a result, having a robust, understandable requirements life cycle is critical. We will need to see improvements in the way requirements are written, tested and maintained.
The testing life cycle
Testing should be like breathing, something you do automatically to keep you alive (5). The testing life cycle is impacted by COVID in a number of ways, first there is the stress on testing infrastructure (tests need to be move to continuous integration (CI) systems). Next, there is an impact on the development of tests when the developer and the test engineer don’t sit next to each other,(6) there is less informal communication that provides bullet resistant (7) tests.
The release process
The smallest mistake early in your development process can have a butterfly effect (8) on the downstream process. The use of automation at all stages of the release process will need to change to prevent the small flaps early on leading to large problems down stream. If we follow the automation upstream we will see that there need to be cultural changes that support people in the use of automation.
The strokes
The strokes are updates to classical Model-Based Design topics; areas where the existing shortfalls are exposed by the current working conditions.
- Cultural
- Improving formal documentation
- Enhancing and simplifying informal communication
- Meeting your meeting responsibilities
- Welcome aboard, on-boarding at a distance
- …
- Process & “Style”
- Workflows
- One of these things is not like the others: Version controls
- What I’m expecting: writing requirements
- Follow the leader, improving the traceability process
- Get your MBD license: Certification time!
- …
- Architectural changes
- Mega fauna models : “Right sizing” your models
- Come together, right now: model integration
- They have a word for that in… Selecting the correct modeling language
- Multi-generation code development: integrating legacy code
- Put on your model reorg boots!
- Baskin Robbins 31 flavors of models
- …
- Development changes
- Workout routine for physical models
- How do you know what you know? Validation methodologies
- Polymorphic functionality
- I think I’ve written this before! Revisiting reuse
- Testing changes
- A shock to your testing cylce
- Send in the robots: test automation
- The ABCs of testing interfaces
- No bubbles: standardized testing
- …
- Workflows
- Automation
- Look at this cool thing I wrote: when and how to automate
- Compound interest: return on investment for automation
- The ice cream problem: bullet proof automation
- …
I will be posting blogs on these topics about once per week.
Footnotes
- I write “could” because all changes are dependent on taking action; now is the time to start.
- I have often wondered to what degree the Pointillism school of art influenced early computer graphics which were sprite based; I also have wondered if the term “sprite” is in part, due to the number of early fantasy computer games that included sprites.
- I tried for a long time to think of a “Spooky action at a distance” joke that would fit in here but wasn’t able to. Perhaps you could say after working as part of a team for long enough you know how everyone thinks, so you are “developing at a distance.”
- Even when you don’t need to simplify the model, real world validation is often recommended for complex systems.
- We could push this analogy pretty far; under stress you breathe/test more heavily. If you train your systems you can run much harder before you are out of breath
- In the best cases, organizations have separate development and testing roles. When they are combined into one, developer is the test; you are sitting next to yourself and sitting alone which can lead to developer bias in the creation of tests.
- I write “bullet resistant” not “bullet proof” in recognition that to get to “bullet proof” is part of the process of validating your tests (see this on developing testing)
- The more common use of the butterfly effect relates to chaos theory, e.g. a butterfly flaps its wings and triggers a tornado. However when I first learned of this it came from a Ray Bradbury story, the Sound of Thunder.