What is your take on software bugs? Do they ruin your day? Do you view them as opportunities to learn about your systems? If someone wrote a clearer specification or wrote another unit test we wouldn't have them? What do you think?
What is your take on software bugs? Do they ruin your day? Do you view them as opportunities to learn about your systems? If someone wrote a clearer specification or wrote another unit test we wouldn't have them? What do you think?
For further actions, you may consider blocking this person and/or reporting abuse
I see bugs as a means of improving. Don't get me wrong, it's so incredibly easy to get disheartened by seeing bugs in your code. But it offers the opportunity for you (the developer) to
A) Improve your software.
B) Learn! It gives you the opportunity to learn something new that you didn't before. This is SO important for a dev, especially when it comes to avoiding stagnating/staying in the same position career and knowledge wise.
Both these aspects are super important to a dev's progression. I think there's a real big stigma about bugs, and the whole notion that every dev should write perfect code, but in reality nobody writes perfect code. If a developer berates another developer because of bugs then really, they're in the wrong. Instead I think good software cultures/environments must have an open culture of accepting bugs as a means of improvement; both in terms of the software in question's codebase, and on a personal knowledge/skillset level. Instead of destroying a developer's confidence over a bug, the situation should result in developers sitting down together and fixing any issues together openly, allowing for every party (and the software, of course) to benefit.
Great answer! "Bug hunting" is also a great way to learn for a person new to a code base.
It depend of the bug I think.
When you spend long hours on a code and they don't know and you don't find why, it's not very cool!
But when you find a bug, solve it and learn how the code work, it's very nice!
Excessive bugs caught in code review reflect an ineffective development process.
Excessive bugs caught in production reflect an ineffective development process AND an ineffective code review process.
I know many of my fellow devs believe bugs are inevitable. And I would agree with that but excessive bugs are a sign of a problem that's worth fixing.
The major problem with bugs is that it takes longer to develop buggy software than it does it develop relatively bug-free software. Steve McConnell does a wonderful job explaining why that is: stevemcconnell.com/articles/softwa...
If you can convince your project stakeholders that it is actually cheaper and faster to take your time, avoid shortcuts, and implement effective quality controls while developing software, your bug counts will plummet. Unfortunately, many people don't want to hear that--so we find ourselves drowning in buggy software.
My role is software testing.
On a good day I view a bug as a curiosity. It indicates a new challenge, how do I isolate it to effectively reproduce, how do I find similar issues?
Other days it is an indicator of failure. When you work at eliminating the amount of testing you do for a given release you're bound to choose incorrectly. My preference is to understand why I eliminated a class of testing which would have caught the issue. My concern is that testing that behavior is expected every release with documentation on pass/fail.
Note automation is used and helpful, but if ever test needs to run every release, and releases don't stop just because you're testing, it leaves no time to reduce time.
I very much view bugs as a error in a developers thinking and as such should be looked at as an opportunity for improvement.