Tuesday, 13 March 2018 09:07

How software vendors destroy their products?

There’s a large variety of CRM vendors on the market right now. Each of them has a different approach to creating their software and it’s mostly based on the actual potential of the company, both technical and personal. I assume that every single vendor would love to say how ideal their product is, and how many tests it has undergone. Unfortunately, in most if the cases, the reality is not always as picture-perfect as we would like it to be.

As an example I could enumerate the IT leaders, such as Microsoft, Google, or Facebook, who provide detailed and elaborate documentation for all the modifications they introduce, and a complete set of instructions for implementing their software. Today, however, I’m going to focus on what I know best - open source CRMs.

One file to easily update your entire CRM system

Let’s imagine a situation where our CRM notifies us that the software we’re using is outdated and requires an update. Usually, we download a single file that only needs to be installed. Once we do all that, we can once again enjoy our safe and up-to-date system. 

In my opinion, the best practice for the vendor would be to release a very easy and simple update mechanism. This solution would speed up and optimize the update process, and make it possible for the users to do it on their own. Otherwise, the vendor will receive countless emails asking

Could it be simpler?

Of course, it could. The easiest way to update your CRM is automatic updates. In this case, the user won’t have to download or install anything manually because the entire can be performed without the user’s intervention. As a matter of fact, several years ago, when our team consisted of only 8 members, this was not the best solution for YetiForce because:

  • we weren’t experienced enough to implement this method,
  • we weren’t sure if auto updates were safe for our CRM, and if we were able to secure them on our own.

Even today it appears that resigning from the auto update mechanism was the right choice.

Update package preparation

Preparing an update package is a quite complicated and time consuming process for the developer. Depending on the release cycle, it can take up to several months.

Number of changes and update quality

The factors that determine whether or not the update process is going to be easy is the number and size of changes in the system. The more changes we introduce, the harder it will be to maintain a bug-free update package.

Test versions

One simple rule applies in this case:

the more testing versions released before the official version,
the better - for us and the code quality.

A few years ago, during the early stages of developing YetiForce CRM, we used to publish one test version before releasing the stable one. Now, before version 4.3 was released, there were 9 test versions, and anybody could test the system online at any time.

Fixing issues

Errors must be patched! Every single user who realizes that the issue they reported has not been fixed will think twice before reporting another problem, not to mention the damaged trust between the user and the developer.

Each time we publish a new version of YetiForce we do our absolute best to fix all the issues reported by our community because that’s the only right way to release good software. Unfortunately, many other vendors publish new versions of their systems, including LTS versions, even though a number of issues from previous versions have not been fixed!

YetiForce needed around 2 years to improve the error patching process before the new versions are published.

Avoiding errors

The key to avoiding creating errors is by writing decent unit tests, both on the system layer and the user’s layer. In an ideal scenario, 100% of the system would be covered by unit tests. In the case of CRM systems, including the proprietary ones, this ideal scenario only applies to a small percentage of them.


I could spend hours writing about how to properly update your system, so could every other software vendor. But how many of us do actually follow our own pieces of advice in everyday life (or our code)? Each vendor has to reach the standards at their own pace, and I’m not the one to judge - you, the users, are.

We just have to remember that

each low quality update package harms its vendor the most

because it takes its toll on his reputation and the product he offers.

Read 1573 times