Improving Wetware

Because technology is never the issue

Working As Designed and other stories

Posted by Pete McBreen 25 Apr 2022 at 03:59

A misconception that some developers hold about testing and quality assurance is that the role of the tester is to validate that the implementation matches the design and/or the documented requirements. The symptoms of this misconception is when a reported bug gets marked as Working As Designed or Meets Requirements, or rejected as an Edge Case that is unlikely to happen in production use.

One of the roles of testers is to act as a User Advocate who protects the interests of the end users. Product owners, analysts and developers sometimes forget that the main goal for software is to improve the life of the users of the software. They can become locked into their own ideas or the existing software architecture and end up creating a sub-optimal user experience.

Architecture at the wrong scale

Posted by Pete McBreen 06 Apr 2022 at 23:03

In a post titled You are not Google Oz Nova points out that many decisions about software architecture are made without really addressing the scale and context of the system under design related to the scale and context of the organization that developed the technology. One of the examples in the post is that of DyanmoDB which was originally designed to support write availability at scale so that Amazon did not lose any “put in basket” actions. In service of the write availability, DynamoDB loses many of the attributes of relational databases that are useful, consistency, referential integrity and easy joins, but few teams that adopt DynamoDB as part of their architecture really need what DynamoDB is optimized for.

In the service of thinking about technology choices, Oz introduces an acronym UNPHAT

  • Understand the problem – then you can produce a solution within the problem space
  • eNumerate the candidates – choose at least three so that you are not doing a simple binary choice
  • Find a Paper to read about each candidate – get beyond the marketing and conference presentation
  • Investigate the Historical context – what was it designed to optimize and what could it ignore
  • What Advantages does the technology have and what are the disadvantages – nothing is ever all positives
  • Think about how well the technology fits your problem space – does it work for your context and scale?

In the wake of this, how many problem spaces really need the complexity of Microservices?