Software Complexity Assessment

The reason behind my many correct predictions on software technologies.

Over the years, I accurately predicted the failures of the following test automation frameworks:

• record-n-playback tools, e.g. HP QTP and IBM’s RFT
• PhantomJS headless testing
• Protractor.js
• TestCafe, Pupetteer, and Cypress
  while these are not deprecated yet, there is a clear sign of moving towards Playwright.
• Selenium-Grid
  It has been completely rewritten for V4. I wrote “avoid selenium grid” in my Selenium Recipes book years ago.
• Gherkin syntax frameworks such as Cucumber and Specflow
  They are still around, but much less hype now.

Not only on test automation, but my predictions on development technologies to avoid were also good.

• SOAP Web Services
• Enter Java Beans (EJB)
• Workflow-based middleware, e.g. MS BizTalk
• AngularJS

An important reason I managed to develop and maintain several highly acclaimed apps, solo, in my spare time: I wasted little time on doom-to-fail and hyped technologies.

In the article, I share my tips: Software Complexity Assessment Rules.

Table of Contents:
∘ Rule 1. Human beings can only master the complexity to a certain (quite low) level unless it is intuitive
∘ Rule 2. Using the language’s own built-in method is better
∘ Rule 3. Using a standard
∘ Rule 4. Fewer dependencies and configuration files
∘ Rule 5. One Consistent way to do the same thing
∘ Rule 6. Avoid Non-Meaningful words for the target audience
∘ Rule 7. Consistent and Intuitive Syntax

Rule 1. Human beings can only master the complexity to a certain (quite low) level unless it is intuitive

A common mistake: humans can easily fall into the illusion that people can be trained and get used to complex stuff. Yes, maybe…