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 —

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


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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store