maramono
Joined 11 years ago
Karma
21
Submissions
26
Member since
May 13
Recent submissions
Comment · 10 years ago
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 wrote about my methodology here: http://ortask.com/wp-content/uploads/fault_localization_impr...
Comment · 10 years ago
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.
More of my thoughts here: http://ortask.com/how-i-designed-built-and-tested-a-temperat...
Comment · 10 years ago
IMO, first we need to solve the smaller issues, most importantly to have developers start making high-quality software consistently.
There is nothing that will get solved with the current "bugs are unavoidable" mentality, which is simply a mediocre and unprofessional attitude.
The way I see it, if mediocre developers try to "solve" world issues, the solutions will be mediocre as well, just like their software.
More of my thoughts here: http://ortask.com/why-your-mindset-might-be-setting-your-sof...
Comment · 10 years ago
If you're already considering leaving, I would take a gamble and tell your CTO/boss exactly what you said and be honest with your employer.
Who knows, maybe they trust and respect you enough to make the right changes and you'll end up loving it there.
All relationships (including professional ones) build; they never start at that perfect place.
Comment · 10 years ago
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.
I wrote a blog post about this not too long ago: http://ortask.com/why-your-mindset-might-be-setting-your-sof...
Comment · 10 years ago
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.
Comment · 10 years ago
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.
Comment · 10 years ago
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.
Comment · 11 years ago
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.
See this video: http://confreaks.tv/videos/mwrc2014-re-thinking-regression-t...
Ortask.com