(In this SmartBits, Tathagat Varma outlines “ How to reduce waste(bugs)?“. The video is at the end of this blog)
It is a holy grail of software development. We have seen from CMM days that defect prevention has been the holy grail. We fail to recognise that a software in itself is not isolated and independent. The context in which it is operating is changing all the time. Be it evolving systems, hardware, software, network or the evolving user behavior.
Ten years back when iPhone was launched, people found pinch and zoom feature very novel to use. Today it is a standard. The context in which people are changing is changing all the time. Definitely that makes sense. It is a good old saying a stitch in time saves nine and we have seen during the waterfall days how the cost of defect amplifies if not prevented. Today, even if we say we are agile, if we were to fix a defect in the production, it still costs a lot. Definitely prevention will have its own role to play.
We are doing a lot of software reuse, whether it is third party or open source. We don’t always have control over a lot of components which we use. We get a component from somewhere and just use that. Do we really have insight into what went into when it was being designed? Do we have control over what kind of defect prevention steps were taken into that? This may or may not be known. We will still need some way of qualifying the components and putting them together and the speed at which we are aiming to really push our systems into production, it will require a lot of us to reuse.
In some sense software construction is being reduced to plumbing the whole thing. It is like the job of an architect when constructing a hundred storey building. We don’t make brick or steel pipes anymore. These just get sourced and are put together and then a system gets created in which we are able to perform incoming check criteria whether this is of the acceptable quality to us. Here some level of a component testing is done to see whether they meet our requirements.
Secondly, we put them together and see whether they really don’t burn each other out. If we put this into the context that we have to release this into production hundred times a day, it’s kind of inevitable that we will end up doing a lot of automated testing. At some point we have to understand that if we are blindly relying on automated testing to solve or uncover every problem, that might be a little dangerous statement to make. We should use it really to make sure that whatever was the behaviour in the last build remains unchanged and unbroken and that becomes a very good verification. If new features/behaviour have been introduced, delegating that to automated testing at the first instance might need a lot of subjectivity. We need to be a little careful. There is no definite yes and no answer but “a balance” probably is the best answer.
