Several qualities are desirable for a reduction software: portability, stability, ease of maintenance, ease of use, short learning curve, good documentation, time and storage efficiency, best functionalities, no arbitrary limitations and last but not least backward compatibility. As we are manpower limited, it is impossible to get the perfect software. We thus have to make some compromises to get the closest possible to perfect. For instance, we rewrote CLASS in FORTRAN 90 although this may bring short-term instability because this clarifies the program structure and it thus eases future maintenance (key to long term stability). We also favor functionalities over efficiency with the idea that CLASS users will be happier to be able to do something a bit inefficiently than to be stuck. Obviously, we always keep storage and time efficiency in mind and we are willing to improve the situation when a widely used feature is too inefficient. Finally, if we make all our effort to have a 100% backward compatibility in data format so that users will be able to do something useful even with even very old data, we can not ensure full backward compatibility on defaults and command names. The easiest way to implement new features (required by improved instrumentation) is sometimes to change defaults and command names though we try to refrain from making those kind of changes without good reasons.