About Quality

As craftsmen we want to achieve the highest level of quality we can achieve when developing good technical documentation, assets such as code or any other kind of product or service.

We can talk about what quality itself means in philosophicaly concrete terms another article. However, we need set of basic criteria to in order to approach this ideal of quality on the topics discussed in this blog.

I have come to understand that any kind of document, being technical or creative in nature, is the end result of a process. This process is similar to the way we develop software applications using code, which requires an infrastructure of tools and activities that range from syntax analisis to peer review in order to guarantee quality.

This quality is enforced in engineering through what we call quality gates, which are predefined milestones where a project is audited to see if it meets the necessary criteria to move into the next phase.

These quality gates can be implemented in many ways, but as humans of humid blood and soft meat, even the best and most disciplined of us make mistakes or take shortcuts to save time.

• This is why we implement them as systems.
• This is why we write tests for every line of code commited.
• This is why we have different people building software components and testing them.
• This is why we use grammar checking in documentation.
• This is why we ask for other engineers to review our work.
• This is why we automate the hell out of these processes using pipelines and CI/CD tools.

The end product should be the result of a systematic process of human or automated agents to guarantee quality control.

About Speed

Some will think that quality can be skipped in software production to achieve a lower time to market.

The reality is that building software is hard. You might be able to get fast in the beginning, but you will most likely not get far.

Since the 70s the best and brightest have gotten into computer science either for passion or profit, and still we find that most software projects fail.

A faulty piece of software at the right place will generate a considerable amount of technical debt that will cripple the development effort on that project, making it fragile, slowing it down and creating hard to solve bugs.

An example of such places where hard to solve pain points appear is the code and queries related to the database access, which might be good enough for the initial parts of a project, but then are unable to scale with the additional traffic or workload requirements.

My argument is that part of the problem are that there are no good procedures for good quality control due to a variety of reasons that might or might not be justified, from technical to business failures.

• Business leaders have their focus on finding good product to market fit over all else.
  • This is necessary for the business to survive.
  • With more competitors entering a market, the pressure to scale up the number of features increases drastically.
• Technical leaders are also at fault for not providing a good plan of action for achieving business objectives and then scaling them up.
  • Creating a good plan is not trivial, specially with highly complex technology with unknowns.
  • Software engineering is highly dependent on talent, which is expensive to acquire, maintain and hard to manage.

One of the reasons why open source software is popular is that its open nature allows for the implementation of quality control systems by the technical stakeholders that depend on it for their operations, improving the product itself over time.

The highway and the jungle

The point I want to take across is that you can only go fast if you have a good highway to go through and a good car. Otherwise you will just crash and burn or spend most of your budget opening a path through the jungle.

One example of a highway is that of the frameworks for web programming, such as ReactJS, Django or Java Spring Boot. It is precisely the fact that these are open sourced which allows the reusability of well tested and high quality components as well of the experience accumulated by countless developers to account for the right patterns for a particular use case or domain.

Another side-effect of the openness of these frameworks is that have gone through this quality control gates over many different organizations as well as very technically capable individuals.

However, this does not guarantee quality, there are many open source projects that have questionable maintenance and quality control mechanisms. Using a framework or open source software is not a green light for an organization to ignore their own quality control mechanisms.

An example of a domain that seems to still be in the jungle, or at least has been for some time, is the VR development area. VR headsets manufacturers such as Oculus, owned by Meta, actively attempts to lock you into their ecosystem. There is still no large big tech that has made the investment to create a generalized VR framework for all devices.

One contender for this seems to be SteamVR, which at least is Linux friendly and maintains OpenVR using a BSD license model. It makes sense that Steam over any other company is pushing for this, because their main business is the Steam store, which might be gatekept by Big Tech stores such as the ones Windows or Meta provides. Ths is the same reason why Google came up with Android and Chrome in order to protect access to its search engine.

Conclusions

In order to go fast and far:

1. We need to use high quality components in our software.
2. We can only use high quality components if we implement good quality control and measuring mechanisms in order to make the right decisions about the activities to be done.
3. Open Source can be a way to access these high quality components if the project is well maintained.
4. Using Open Source frameworks and components are not an excuse not to have good quality control and resiliency plans.