It depends on the difficulty of the bug(s) that need to be localized and fixed.
I use a wide range of techniques from simple printf's all the way to a full-blown methodology that has not failed, especially when dealing with coupled bugs or those caused by concurrency issues, hardware and such.
I've used it several times but the big problem with it is that once you have a nice, correct model that has been checked (and no counterexamples found), there's no way to translate it to code. This meand that your basically back on square one in terms of implementation.
I really like (and use quite often) the ASM method instead.
However bug-free software may be prohibitively expensive to create. You would need military-style controls on every line of code, every change. Specifications going to the n-th degree to be ratified and signed off by all of the stakeholders, who need to be highly engaged and quite technical. No vague requirements allowed. If no one makes a mistake in this process then maybe it will be bug free.
Yes bugs really are unavoidable. That will never change because bugs (other than silly errors) are usually an artifact of translation of user requirements, system requirements etc. into a working system.
However I agree it is feeble to use that as an excuse. It's like saying I won't exercise because I can't ever run 100m in 1s, no matter how I hard I train.
Tooling is definitely an issue. I'm reading "You don't know JS" for fun and learning a lot about why JS is a really horrible language to write bug-free code in. If you are stuck with languages like this (and all languages have their respective problems, if not as bad as JS) then it is hard to write bug free software.
I learned it finding that the feeling I get from it is slightly overwhelmed, mostly because there seems to be so many new things coming up and so much is in flux. I found it worthwhile nonetheless as it's useful for some things and Node is kind of cool actually.
I get a fragmented energy from JS and a more integrated energy from, say, Python.
To produce high quality code you need to change your mindset. No tools will help you if you don't know how to use them. Also you cant simply "pass the buck" (so to speak) to tools and expect greatness. TANSTAFL.
Here's what I use to develop Mutator's [0] and TestLess' [1] GUIs:
- implement in Ruby
- compile to Java using Warbler/JRuby
- Run as Java on any platform that supports Java.
You can use javafx or swing, although javafx needs certain combination of warbler and jruby to work.
Crazy idea: stop usng mocks completely where possible, and install a formal currency process for keeping the existing ones up to date. Mocks are notorious for diverging from the code they are mocking and should be used very carefully.
It also sounds like lack of discipline and management are the root of the problem that needs to first get resolved.
What I find interesting is that there is absolutely no mention of the word 'test' in the spec. With unit testing and TDD/BDD so ubiquitous now, perhaps new languages should be created with testing support baked in instead of it beng added as an after-thought.
There are methods that can be applied to software that formally prove properties of software so that those pieces are free of bugs. These are called formal methods and require heavy use of math. Some of them are ASM and Z.
There are provers that help as well, such as Alloy.
For the typically/average project put there, the mayor problem I see is that people still rely on code coverage as the one and only metric for quality of their tests (if they even implement tests at all).
Code coverage is a lazy, flimsy and unreliable metric that has been subsumed by the more powerful metric called mutation score.
If devs utilized mutation analysis more, they would provably have much better quality software.
TL;DR: Matt Wayne (the interviewee) talks about a basic problem that agile was supposed to solve: creating software that actually satisfies business requirements.
For him, Cucumber and BDD solves this problem.
But for all other bugs and code defects that happen during software development, mutation analysis works great at increasing the quality of unit tests: https://en.m.wikipedia.org/wiki/Mutation_testing
I use a wide range of techniques from simple printf's all the way to a full-blown methodology that has not failed, especially when dealing with coupled bugs or those caused by concurrency issues, hardware and such.
I wrote about my methodology here: http://ortask.com/wp-content/uploads/fault_localization_impr...