Thoughts on tech

Publish date: 2022-01-11

Tags: thoughts qa microservices

Throughout the years that I’ve worked I always tried to learn from the mistakes I’ve made and the problems I’ve encountered. Based on those experiences I’ve collected and documented some ideas and thoughts regarding product development, team ops, web architecture, QA processes and web standards. As the saying goes, “All truly wise thoughts have been thought already thousands of times”, some of the points I’ve collected have already been written and shared by someone else, so I’ll try to include links and references to further develop an idea whenever I can.

Websites

Lighter websites = faster websites ⚡️

As everyone should agree faster websites are always better, but many companies still don’t focus on speed and lightness as much as they should, as time passes many website become convoluted and thus, they became slower.

Websites should always aim to optimize the user experience by making their websites load faster and use less resources, this can translate in better engagement from users and increased revenue per user ¹, this has been proven more than 10 years ago. Google saw that for each 500ms in latency a decrease in 20% of their traffic, Amazon saw for each 100ms in latency a decrease in 1% of sales. This was true at 2006 and it’s still true, speed matters.

The increase in websites weight and slowness is better explained, and with much better humor, by Maciej Cegłowski on his now iconic talk: The Website Obesity Crisis.

Using microservices

As a rule of thumb, don’s start a project using microservices, thats it. Martin Fowler explains it way better than I could on his post MonolithFirst, as well, I’ve always liked the way David Heinemeier argues in favor of monoliths on his post The Majestic Monolith.

Both of them surely know better than me why is not a good idea to start a project using microservices.

Maintaining quality in software

Testing software is HARD

Software is complex to write, and thus, it’s complex to test. So, in order to increase the quality of the time a team spends testing, it should embace automation early on, and on every step of the development process. Teams should consider the following:

1. Start by automating the most common use cases (Pareto Principle): By focusing on automating the most frequent test cases first, teams can start to run those tests as regressions whenever they add a feature, so they can ensure new changes don’t break existing services and filter bugs early on
2. Whenever you fix an error, create a test so you never repeat yourself: Nobody likes bugs when using a service, so whenever a team fixes a bug they should aim not to make the same mistake again by adding new tests, doing so they’ll increase the test surface that can be used in the future. This tests compound over time and will increase their value as time goes by.
3. Create test cases, per feature, early on: Whenever a feature is under active development tests should be written and, if possible, validated even before a feature is complete. By making this part of the process, both developers and testers can increase the quality of the features.

QA should’t be an isolated process

In general, when we talk about software processes people refer to QA as a stage that’s done after the development is completed; but in order to achieve better quality on a product, testing shouldn’t be seen as the last step on a process. Product teams should embed testing as soon as posible in their development process and encourage cross-team collaboration.

A great introduction to this way of interlacing testing with development was written by Mark Hrynczak at Atlassian, and can be read in Quality assistance: how Atlassian does QA

Documentation

Great companies have great documentation (or they should)

If startups have excelled in something it has been writing and maintaining great documentation, and I believe this investment yields an excellent ROI. Great documentation empowers customers and developers by allowing them to iterate and launch products faster.