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.

 

From the perspective of choosing how and when to work on them, I view bugs as just another requirement that hasn't yet been implemented: it needs to be prioritised, understood, tested, built, etc.

From the perspective of when I'm working on it, it suggests a gap between a developer's understanding and reality (as david karapetyan mentioned above), but my immediate reaction is "why didn't a test pick this up?". So my first response is to look at the testing around the bug to understand whether there's a missing test, or a test that's not replicating reality appropriately.

If this part of the codebase has a history of bugs, then I might think a bit more broadly about how we've modelled this area and work out whether there's a mismatch at a broader level. What is it about this nook of the solution that is a bug magnet? Is there a need to redesign the solution to bring it closer to our current understanding?

I don't work on anything where a software defect could hurt people, thankfully, so I don't believe 0-defect software is a realistic or viable goal for most software development houses. Therefore, I don't beat myself up when I (or others) create defects. I accept errors in my work, try to understand how to find them quickly and reduce their probability, but try not to let the presence of defects impact me significantly.

 

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.

 

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!

 

I see bugs as a mismatch between my mental model and what the code is actually doing. I don't think more tests help because most software systems after a certain point are almost impossible to test. Only way to find out if something is broken is to actually run the whole thing.

This is why I'm skeptical of TDD in general. Tests help but it is much better to invest in tools and architectures that make software systems debuggable. My views on this are colored by what I saw in smalltalk environments when I first started programming. I've yet to have a debugging experience that comes close to replicating what is possible in smalltalk. Erlang/elixir/lisp are close second in terms of live debuggability. Everything else falls short in one way or another and is often downright user hostile.

 

I very much view bugs as a error in a developers thinking and as such should be looked at as an opportunity for improvement.

Classic DEV Post from May 10 '18

Elixir vs Ruby - where to use?

The comparison of Elixir and Ruby features to consider for using for different.

Alan Barr
Software Testing Architect passionate about getting people into homes. Learning new things about technology and software that helps people.
Join dev.to

Better understand your code.