What are the hallmarks of quality? This is a vital question for us as a software development company because it affects our business: the number of new customers, their satisfaction of our work etc.
In most cases developers are really trying to create high-quality products. At the same time according to statistic only 30% of completed projects satisfy customers. Actually it means that most of money and efforts are either wasted or used ineffectively. Why does it happen? What is quality? These two questions really are the same.
There is no single answer. Quality consists of many different aspects. One system seems to be self-documented and easy to use. At the same time you can’t start using the other system without reading manuals or undergoing trainings. Why does that happen?
Does quality mean usability? Absolutely!
Does quality mean performance? Of course! There is nothing more annoying then a system that works slowly at the end of working day, when you must get a result before you can go home.
Does quality mean error absence? Sure! Nobody will be happy if the system doesn’t do what you expect. Is it safe to allow such a system to work with your bank account? We don’t think so.
Does quality mean security? Exactly! Nobody will be happy if hackers can get your personal information, or confidential data.
High-quality systems should be realistic. How difficult is it to change a system if something changes in the world or your business? How much time does it take? These questions are also related to quality.
How to achieve quality?
How to build beautiful and convenient houses? How to build high-quality systems?
It is very important to understand that creating a new system is a conjoint process, both customers and contractor must work as a team. There may be different types of people, different roles, but in any circumstances it must be a team of like-minded persons. Otherwise it is very difficult to provide quality.
— Knowledge and experience
Knowledge allows to choose the right way, experience allows to avoid mistakes. We successfully completed a lot of big projects. Of course we made some mistakes. We have learnt from them, and won’t repeat then in the future.
One of the most important things is to be able to listen and to understand customers. It is an ability to ask the right questions, notice all the relevant details. It is an ability to listen to customers, allowing them to express their individual thoughts. It is a ability to formulate system requirement by ourselves while helping customers define their system needs. Our analytics can do all these things. As a result you will get a functional requirement document (FRD) that clearly describes what you need. This is the first component of your future system that is quality-oriented from the beginning.
Even detailed functional requirements can’t state everything. Some questions will appear only when we start development work. Having signed an FRD we might disappear for a few months and later come up with a completed system. But that is not what happens. We use every opportunity to keep in touch with our customers, to show a UI design, a prototype, some completed modules etc. in order to get feedback. This approach allows us to clarify missed questions, avoid different interpretation of the same things, and to catch potential errors in the early stages of a project. All these things affect quality.
When the first version of the system is completed something always needs to be changed, sometimes dramatically. This happens because of a changing environment, your personal understanding, your evolving business, and so on. But it happens always.
We have not written flying control systems so far. For other systems we use an iterative approach. We try to divide projects into a few stages (iterations). After the first one you will get only the most important features and use-cases implemented. The rest will be done during iteration 2, iteration 3 etc. It is not easy to agree with this approach especially if you never worked with us before, or never worked in software development. Many people want everything at once and as soon as possible. But our experience says that creating a whole system at once means big changes in the future. Small iterations allow you to get results in a short time, to check it and use it. When you implement the first version of the system we will get the most valuable feedback, which is what allows us to provide high quality.
Test Driven Development
Our development process is based on a methodology known as “Test driven development”. It means that we create tests in parallel or even before the system goes on-line itself. It means that the quality control mechanisms are built in a system from the beginning.