Similarities in Quality Assurance between Cambodian Silk Painting and Software Development

I am currently travelling South-East-Asia and have some time to think and to absorb new ideas and impressions. Beside the personal interest and impressions, I have some time to think about technical and quality stuff as well.

For some clients, I have trouble to explain the difference in the quality processes between software development and classical production processes. Today, while visiting a workshop in Siem Reap, Cambodia, I saw how silk paintings are painted. The interesting fact was how the paintings are copied to sell a picture multiple times and to be able to sell it as originally hand-painted. There was a master painting standing at the wall. The painters used it as template and each painter draws her pictures as similar to the template as possible. A quality inspection checks the work afterwards on the final product to select work to be sold as class A or class B, which is to be reworked and what is to be disposed.

I found it a good metaphor for software development, with one minor tweak. The metaphor (and the tweak) is want I want to explain in the next paragraphs.

Quality Management was developed originally for building heavy machinery like cars. All statistics and processes are developed for a single process building a single product in mass production. The better the process is, the better the outcome quality is. Therefore, the focus is on the process and the measurement of the process capabilities and dealing with the facts coming out of the measurement process. Quality Management for heavy machinery is very well-developed and mature and has proven to lead to high quality if used accordingly. The main focus is therefore on the manufacturing process.

In Semiconductor Industry, the process is still present, but the products are produced in parallel with thousands of chips per wafer in a single production process. The statistics become more difficult and needs to be adopted. The chips which are on a single wafer are not statistically independent and the statistics need to be applied on per wafer level. The process is still in focus, but there is already an issue to use the production process which is applied once for a lot of chips in parallel as quality measure. The process and its process parameters are not enough to know the quality for all chips on the wafer. There are too much uncertainties. A detailed final test on each chip is needed to be sure about the quality of each chip.

It is the complexity of the parallel production process which breaks our quality process neck here. One process builds in parallel the same product, but the process can have issues which are not measured with process parameters. The process is monitored classically, but the the parallel production can not be monitored detailed enough to use the process parameters alone for quality assurance.

The software development process fits neither the car production nor the semiconductor process. It is even more complex and no recurring production process is present. The process can be compared with the silk painting mentioned at the beginning: Each ticket (It can also be called work item, work package, enhancement or change on source code. It doesn’t matter how you call it.)  is worked on manually by an individual and all of these changes are totally independent to each other. There is no common process for creating source and no statistics can be applied. A process can also not be introduced because each ticket is different and there is no common work pattern for the source code change itself.

In painting, I also have seen pictures painted by two persons in parallel. It is more complex since you need to control two people without a fixed manufacturing process. A final product inspection is the only chance to assure quality.

In Software industry there is nothing like a practical production process which is applied regularly and the first result coming out of the process is copied hundreds, thousands or even millions of times and shipped to the final customer. There is also not an easy statistical approach to the software making procedure. It is true for silk painting, too.

The difference and point of increased difficulty in software development is the fact that there is even no template for the source code change to make. This is the twaek in the silk painting metaphor. The source is built every time completely independently without any practical constraints during the work.

For silk painting the quality control is a check afterwards on the final product where the quality department checks for the correctness of the work. This is something which can be done and is done by manual and automated source code reviews. This is a first step in the right direction, but what is the right measure? What is the template to apply?

In software development the template are coding conventions, API rules, design rules and architecture constraints. These constraints need to enforced as rigorously as possible. For Java as example, there are tools available like Findbugs, Checkstyle, PMD and others. These tools need to be set in process to bring a certain quality into the actual work. This targets the maintainability of the software. This is comparable with the silk painting process itself and how good the painters are in copying the template. How good the template is, is a question of the template painter. In software development it is the quality of the design, the architecture and the rules for the source code to be check automatically.

I find this similarities quite interesting and something to think about it in the next time. Maybe there is something coming up…