Q stands for Quality

As one of our CEOs, Matthias Meisdrock, put it at the Bosch Podcast:

Companies like us do something different and something better, they do better at core functionality. As a company, we work on improving our core functionality every day, and that ensures that we will have the best product in class for a long time.

In order to offer the best product, all the product levels should be held to that claim. This also includes quality management. The software should be as flawless, stable and reliable as possible.

This article is based on a Bosch podcast he was invited to, where he talked about quality source code, and aims to showcase the process that the developing team goes through to ensure our product consistency and quality, as we believe it is important to not only offer quality but to also be transparent about how we do it.

Designing the new feature

We start from the basics, from the foundation of every product which is its features. Code quality starts as soon as we consider adding a new feature to our product. We know it will require maintenance and it has to have a purpose further down in the future of the product, not just a quick fix or a simple plus. This could create issues late, as with each new feature potential errors arise and the software might turn into something complicated for the user.

Another important point we take into consideration is if enough customers want it, as maybe the new feature is useful for just one or two and it would not make sense to develop it. So to summarize, the feature should fit both our customers‘ needs and our software concept, because it is senseless to implement something that does not fit into our product family.

Customer Centricity Approach

To plan the new feature we talk with our customers and understand what the problem is or what they want to achieve. We usually do this with one customer that definitely wants to have a new feature, share the team’s ideas, discuss with the customer about a possible solution and find out the best way to implement it.

Writing the Code

We believe that if you take excellent care of the components inside the software, then you also have better quality on the productive stage. And if the product is better, then its usability is higher, as well as its efficiency.

This idea is not new in the industry, as big companies such as Apple carry the same approach. Steve Jobs admits in his biography that his attention to detail started because of his adoptive father, who was a mechanic, and insisted in doing things right, even in the parts you cannot see. For us it allows us to create features with the following pros:

• easy-to-use software
• efficient coding and functionality
• faster implementation of future features
• easier problem finding
• easier problem fixing
• simple function changing

After planning the feature, we start writing the code. This process is clean and structured, so that each feature has its own branch of source code. In our case this means creating a ticket description of the feature and assigning it to the matching source code via the version management system managing the source code. This is followed by the review, testing and final quality control processes. These processes are clearly defined, revealing the majority of feasible problems at an early stage.

For us, good source code is the essence for high quality. In our opinion, one of the most important characteristics of good source code is its readability. Our CEO learned this early on in his career. A CTO he admired, explained to him why is it crucial to write good source code and why it should be continuously improved. He further explained that you should write the code for a feature three times to make it suitable and functional:

• Write the code to understand the problem.
• Implement the solution.
• Make a perfect implementation.

Details play a huge role in writing source code. We examine it together as a team to make improvements or learn from one another. We do this as it has been proven for us over and over again that we get a better feeling on how to write code by talking about it. The discussion centers around how to do, for example, the following subjects:

• structuring
• name objects
• separate code formats from each other
• name functions
• how big functions should be
• how many if-blocks we have in each other
• how to handle for loops, etc.

After reviewing it several times, we can move forward to the testing stage.

Usability: Why are you creating this feature?

For each function in the feature we do unit tests and integration tests to make sure we will not have any future issues. Additionally, here we can also prevent any potential side effect by doing so.

Every time a branch is pushed, these built-on tests are executed and the results are available on the server for every developer to see and review. After this, we test it again by hand to check if the new function does what it should do.

Safety-relevant features and functionality concerns are discussed repeatedly in the group.

The implementation is revised until the feature is accepted by a reviewer. Then, in weekly meetings the new functions are tested and approved by the group. After the manual testing, the function goes into beta phase, which means it would go to a chosen customer to be tested in production.

Quality: How good is the feature working?

During the duration of the whole project, the results are presented and analyzed together with the customer constantly. This way, we receive feedback, and we can go through any suggested improvements. When a feature does not function properly even after doing all this process or it does not solve the targeted problem, it will not be published.

From Beta to Production

In the next stage, the customer gets this function for use. The beta/version goes to a staging server where some selected customers can work with it and test it. With this beta version, we can also discover and fix problems that would not be visible before its practical application.

After a successful beta phase, the feature will be released on our productive servers and announce the new product version. We release new versions every three to four months. To solve pressing errors at short notice, we push hotfixes.

Monitoring

We are constantly monitoring log files where we can identify possible inconsistencies. We evaluate potential problems in the weekly meetings. The key point here is to react quickly and follow up with the improvement.

Hotfixes

Any errors that occur are first replicated as a test and then corrected in the source code. Beyond correcting the error, we investigate how it could have been generated. For example, we analyze whether source code was merged incorrectly, the documentation was ambiguous, or the structure was written in a way that the reviewer could not detect the problem. Bugs are often the result of poor code structure, poor architecture or poor design.

Conclusion

It requires really hard work and a dedicated team to ensure high quality of any product, in any industry branch. Software development is not any different - as you can see, there is a lot of detail reviewing, teamwork and constant learning.

At OMQ, we are committed to provide the best and uppermost quality of customer service automation software. We work with the utmost attention to detail in every step to actively shape and develop the future of this industry.

If you are interested in any of our customer service solutions or have any questions, you can always contact us! :)