Silicon Valley and Agile are Ruining Engineering
Silicon Valley and Agile are Ruining Engineering (AND decimating industries and harming people for no reason)
The scientific nomenclature = The Silicon Valley Agile Holiday Inn Express Syndrome
First, “Agile” bottoms up approaches can be just fine or even the best option. That is where the folks doing the work do not work form someone else, are selling their own product, determine their own schedule, costs, scope etc, and the systems are not complex, or safety related.
Now to the issue at hand. There is a disease infecting the world. It has migrated into governments and even NASA. This disease is the Silicon Valley Agile Holiday Inn Express Syndrome.
(For those unaware of the Holiday Inn Express part — https://www.youtube.com/watch?v=eHCTaUFXpP8&list=PLzvTUNG--HJ2fFCph1_SeaxAatPngsMVp)
The Symptoms
Lack of Systems Engineering or Systems Engineers
Systems engineers are responsible for functional decomposition to technical requirements, the systems design and testing of that design. (QA or QC would spot check that.) Without this little effort is being applied to systems decomposition, dependencies, what-if scenarios, negative testing, or exceptions. These are actually more important and will require more work than the intended or “happy path” in many instances.
Lack of Best Practices — In addition to Systems Engineering
· Use of Activity or Use Case Diagrams vs words and stickies — All this does is produce a giant pile of words and paper with no ability to see or visualize the building system. If you used diagrams it would facilitate far better understanding at the time of design but also for training later. And it could be used to document and communicate changes.
· FAGEN Code Reviews — Hold code reviews before Unit Test are done to avoid bias. And try to have the folks who write the tests are not the folks who wrote the code. Often mistakes just get pushed through the whole process and tests pass.
· Metrics like requirements Volatility, Defect Density and Rework
· Test Coverage — All test lifecycles
· Lack of root cause data for defects — To include what lifecycle processes(s) were involved, which groups were involved, design and code review data etc
· Earned Value Management
· A WBS with full decomposition
· A schedule with full decomposition and dependencies
· More in my article below
Move Fast and Break Things
Yes, this makes sense overall. But only after the engineering due diligence I mentioned below is complete. Also, few undertake exception handling or what-if efforts, leaving users to stumble through them. In the case of autonomous systems development the public is functioning as needless guinea pigs so these can be stumbled on.
(Just in case someone brings up SpaceX. In 2011 NASA failed SpaceX code for being very poorly tested and having almost no exception handling. The most important part of the system. How did the development lead for SpaceX at the time, who came from gaming, handle this? They hired more actual aerospace engineers to augment the IT folks.)
The Miracle of Divine Experience — Silicon Valley Agile Holiday Inn Express Syndrome
This is where folks think doing one thing or working in one domain means you miraculously know much more. Meaning making Twitter (literally) prepares you to make an autonomous vehicle or aircraft. Along with this goes the extremely exaggerated belief that no one else has innovated a thing. In most cases you are wrong, especially in the areas I refer to in this article. Making a social app does not give you experience in most systems engineering, automobile design, sensors, machine learning or deep learning by default. An example being sensors. Other than spinning LiDARs you are doing nothing new other than making things smaller. And in most cases like radar what you have works very poorly compared to DoD, aerospace etc. (Yes, deep learning and machine learning are mostly new for everyone, at least to the scale and complexity being used now.)
Echo Chambers, Ego and Maslow’s Triangle
This is the natural affect of humans in groups, who have little experience or exposure to other disciplines or domains and the ego’s desire to think you are killing it compared to everyone else who has ever lived or lives. Maslow’s hierarchy of needs explains the ego, need to belong and monetary portion of this. Also, echo chambers rarely self-correct. Often it takes a strong outside force like tragedy, laws, lawsuits, bankruptcy etc.
Where is the Infestation Most Critical?
· Autonomous Vehicle Industry — Both the air and ground domains — See more in my link below for more
· Urban Air Mobility — Many of the folks designing eVTOLS etc have little actual experience. And the Air traffic Management approaches, especially those led by the FAA and NASA, are woefully deficient. See my link below for more
How We Got Here
The history involves why Agile was created in the first place. It was created because folks were struggling to meet cost and schedule estimates and commitments. Since they assumed (incorrectly) they were already using the best PM and development practices, these folks assumed the only thing left was to diminish project size and complexity. While there is some virtue to this, it was extremely misguided. This led to the pendulum swinging way too far the other way. The projects were downsized to a single subsystem with folks stumbling on new subsystems as they discovered they were needed. This led to a far worse problem than the one they were trying to solve. Instead of trying to know to much up front, which can occur, these folks now ignore too much. Now add to this the lack of best practices, the miracle of divine experience and the mechanics of echo chambers, ego, and Maslow’s Triangle it’s easy to see how we arrived in our current state.
The Solution
Obviously, the solution is to remedy all the items above. I would suggest though the most important step is to recognize the perfect storm exists in the first place. Beyond this the approach that works best, most often. That being progressive top down and bottoms up due diligence, augmented by actual best practices. All that means is, do the best you ACTUALLY can from a top down POV and employ the practices I listed above. Where you do not know something or do not have a high confidence you know something, handle that with how this area would be in the schedule, especially relative to dependencies. Then factor in a productivity rate that accommodates it. From here build a best guess Sprint Plan that shows all, and I mean all the subsystems, their dependency maps, time to complete etc. Then iterate on this as time goes by.
Finally, just to tweak some of you a bit more — I have no degree — Discuss
More in my articles here
The Autonomous Vehicle Industry can be Saved by doing the Opposite of what is being done now
Urban Air Mobility — Four Paths to Disaster
· https://imispgh.medium.com/urban-air-mobility-four-paths-to-disaster-9dd3966f85e2
Commercial IT Lack of Best Practice Use — Negligent?
Diagrams or Process Maps vs Stories or Use Cases — Critical to Avoiding Waste
My name is Michael DeKort — I am a former system engineer, engineering and program manager for Lockheed Martin. I worked in simulation, as the software engineering manager for NORAD, as a PM on the Aegis Weapon System and lead C4ISR systems engineer for the DHS Deepwater program. I am now CEO/CTO at Dactle.
Key Autonomous Vehicle Industry Participation
- Founder SAE On-Road Autonomous Driving Simulation Task Force
- Member SAE ORAD Verification and Validation Task Force
- Member SAE G-34 / EUROCAE WG-114 Artificial Intelligence in Aviation
- SG3 ML Design & Verification and SG4 ML Implementation & Verification
- Stakeholder for UL4600 — Creating AV Safety Guidelines
- Member of the IEEE Artificial Intelligence & Autonomous Systems Policy Committee
- Presented the IEEE Barus Ethics Award for Post 9/11 DoD/DHS Whistleblowing Efforts
