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 initially, but with time, the complexity gradually takes its toll. The reason is simple: human beings' tendency to simplicity.

In 1999, I worked as a research scientist at the research centre, my team leader was on the advisory board of a W3C group (only a handful in the world). One day, I found an XML schema error (namespace related) with Resource Description Framework (RDF) while developing a parser for it.

I asked my team leader, “If the XML schema experts could get it wrong, what’s the chance for average software engineers?”. My team leader smiled and showed a sign of agreement but didn’t comment.

Later, I started contracting work as a programmer. Almost at every job, people came to me for XML schema questions, including data architects.

Do you remember SOAP (Simple Object Access Protocol) web services? Over a decade ago, SOAP was everywhere. Even though its name contains ‘Simple’, it is not simple (XML Schema based) for most programmers.

As you know, SOAP has been replaced by REST; XML is replaced by JSON as the data exchange format (JSON does not have namespaces). By the way, XML is a simplified version of SGML.

Rule 2. Using the language’s own built-in method is better

Suppose one team’s star programmer creates a more efficient (1% better)array sorting method.

numbers = [2, 9, 7, 5, 3]

def efficient_sort_array(ary)
  # implementation here
end

sorted = efficient_sort_array(numbers)

I would be against using it. Why? Even though it may be 100% bug-free, team members must remember this method's name and which package to import from.

Using the array’s built-in sort() is better.

sorted = numbers.sort()

Because you don’t need to explain this to another programmer.

Rule 3. Using a standard

In code and test scripts, we can use regular expressions to scan or extract text based on a pattern. If someone says “regular expression is old and complex” and implemented his own “simple” way, DON’T use that, stick with Regular Expressions.

Regular expression has become a standard and well-tested, and almost all programming languages support it. People can learn it separately. Beginners can find good free online resources, such as Rubular, to try out and verify.

By the same token, Selenium’s Xpath locator is good.

The Rule 2 and 3 (and maybe Rule 4 as well) explains why so-called self-created automation framework always fail. Check out my article, Please, Not Another Web Test Automation Framework, Just Use Raw Selenium WebDriver.

Rule 4. Fewer dependencies and configuration files

To set up test automation execution for Selenium, it needs the following:

• Chrome browser

• Language runtime, such as Ruby or Java

• Selenium library, such as selenium-webdriver gem or selenium.jar

• Syntax framework libraries, such as rspec or junit

• ChromeDriver

Note: Appium adds starting the Appium server, which is more complex.

You might have heard people complaining, “Selenium is hard to set up”, which is not necessarily true. For Cypress or Playwright, probably only one less item: ChromeDriver. Also, ChromeDriver is very easy to install/update (just one executable). See, just one simple item, some vendor’s marketing team can use to defame Selenium.

There is a solution. For example, download and install the TestWise Ruby edition, which sets everything up in a couple of minutes: download, launch the installer, and press the Enter key until it is finished. Easy!

Also, configuration files add complexity. Below is a playwright config file.

const { defineConfig } = require('@playwright/test');

module.exports = defineConfig({
  use: {
    headless: false,
    viewport: { width: 1280, height: 720 },
    ignoreHTTPSErrors: true,
    video: 'on-first-retry',
  },
});

Because configuration files are detached from the main (such as test scripts), they can get out of sync. Therefore, the fewer configuration files, the better. Selenium WebDriver, by default, has no configuration files 👍.

Rule 5. One Consistent way to do the same thing