Embedded Development Lesson: Isolated Learning Delayed Human Mastery of Tetris for 36 Years
Darwin Sanoy
Field Chief Cloud Architect | Innovation Fanatic | Economic Mobility Volunteer
The book "Get Better at Anything: 12 Maxims for Mastery" shares a fascinating insight on how Tetris was only mastered by humans after 36 years. What is the cited cause for this?
The emergence of collaboration through observable working examples.
To prove they weren't cheating, folks that were mastering this game were forced to publish internet videos that showed both their screens and their hands at the same time. This caused a positive feedback loop which created exponential gains in game performance as shared gaming innovations kept being republished. In the words of the book, this created a "See:Do:Feedback" loop.
This made me reflect on the isolated nature of Embedded Software Engineering through what I'll call "Workbench Isolated Development".
Due to a long legacy of hard problems, like dependence on hardware, Embedded Development has been isolated to each individual's workbench. The trend toward isolation continues where ever there is an emphasis on the IDE as the primary place where Embedded innovation happens.
DevOps claims that properly solved technology problems include "People, Process and Technology". The failure to understand how to transform the People and Process parts is frequent and somewhat natural when trying to apply DevOps to a domain such as Embedded.
Yet, accounting for People (aka culture of shared innovation) and Process (aka mechanism of shared engineering excellence) in Embedded Development is crucial for software innovation in this space.
If an embedded development workflow does not include the ability for peers to review each others code, you are missing out on the level of innovation effects that the Tetris example suggests is possible. You are missing the "People" part of DevOps - a culture of shared innovation.
领英推荐
GitLab enables great strides toward adding the collaborative workflows of DevOps to complement the Embedded Developer's isolated workbench experience (which can't always be eliminated).
In GitLab, people's collaborative innovation is unleashed using the Merge Request for code changes. This is where you watch the hands and screens of other coders. It is where existing mastercrafters can guide and grow team members. The GitLab Merge Request integrates seamlessly with automated build and testing processes built in Gitlab CI. This further enhances collaboration by encoding software manufacturing wisdom in shared, repeatable, machine automated processes.
Here is a working example of converting an existing Workbench Isolated build process into GitLab CI. It is a set of self-paced Proof of Concept tutorials that have low hardware requirements so any team can see and feel how they might apply DevOps to their existing Embedded development workflows:
"Get Better at Anything: 12 Maxims for Mastery" also talks about "automating practice" to master a craft - as in how skills become instinctual even though we are not born with them. GitLab's new CI/CD Components support the "Process" part of Embedded DevOps by unleashing a whole new level of encapsulating and sharing software manufacturing know-how in ready-and-easy-to-use nuggets.
Here is a GitLab CI/CD Component that enables you to bring any Hardware into the CI Loop and enable automated, global hardware sharing in an On-Premise Device Cloud. It uses only GitLab functionality. The information includes a 5 part video series on why and how to implement the device cloud:
#embedded #embeddedsystems #firmware #iot #embeddedcicd #embeddedops #embeddeddevops #hil #hilengineer #devopsplatform #devsecops #softwaredefinedvehicles #sdv #automotive