As the number of bugs in a codebase increases, that number not only decreases the quality of the code, it also affects the mindset of the developers. Developer self-confidence falls when things are not going well. If self-confidence is not right, things more easily become a mess. How do you guys keep your self confidence up in these situations?

  • 10
    My solution is tequila (for everything, ever). – yannis Apr 3 '13 at 5:36
  • Every rule in The Joel Test serve to improve developer confidence and efficiency. Frankly I have nothing to add on top of it. – rwong Apr 3 '13 at 5:51
  • 1
    @Yannis: Tried Tequilla one - too much, way too much - can't drink it now. Scotch works though – mattnz Apr 3 '13 at 7:36
  • @YannisRizos beware the Balmer peak xkcd.com/323 – Martin Beckett Apr 3 '13 at 16:16

Learn about these:

  • Get to know the language better - starting with introductory books and then move on to advanced ones
  • Basic algorithm proofing techniques
  • Unit testing
  • Integration testing
  • Combinational testing

The purpose of knowing the language better and learning basic algorithm proofing techniques is to be able to reason about the execution of the code with high confidence.

The purpose of combining multiple testing methodologies is to get an assurance that the code is able to perform correctly in as many cases as possible. By using algorithm proofing techniques (and maybe combined with some code coverage tools, if available), it is possible to get an exhaustive case coverage without having to exhaustively run through all combinations of input parameters.

  • Spot on; I want to point out that the key insight that lead to TDD was that without tests, you can't be sure that your code changes won't break something unexpectedly, which makes you reluctant to improve existing code. To fix this, you need to have a good test suite first, and then continuously improve the existing codebase (refactor early, refactor often). – congusbongus Apr 3 '13 at 6:34

If you need help with keeping up your self-confidence, you probably need to talk with a personal councillor about that.

But it sounds like the problem here is that your project / team is in a dangerously disfunctional state. You / your team should be using on or more of the standard approaches to keeping code quality high and bug counts low:

  • Use code reviews, code inspections or peer-programming to get "two sets of eyes" on the problem.
  • Build unit and system test suites, and run them on a CI server.
  • Use automated bug detectors and source code analysers to pick up common bug types.
  • Use a bug tracker.
  • Use a coding standard.
  • Use code quality and test coverage metrics (intelligently ...)
  • And so on.

If you keep on top of the number of bugs, you can be confident ... AND produce a good product.

Of course these things all take time and resources (people). But your management should be providing these ... or risk ending up with a codebase that is unreliable and unmaintainable with nobody left standing to work on it.

If you are stuck in a disfunctional project / team and it is seriously affecting you, you should consider making a move. Not all projects and not all organizations are like that. But maybe the flipside is that you need to learn to not take it personally when things go badly through no fault of your own.

  • All of this is for nought if the management at his organization is the driving factor; telling them to release with the bugs in and move on, not worrying about them until they get enough complaints from customers. This is a management approach in a variety of places, and all the technical solutions to quality in the world won't solve this; sometimes a managerial solution is the only reasonable one. – Jimmy Hoffa Apr 3 '13 at 13:54

Fix the bugs?

Seriously, all developers make bugs. They're not a sign that things aren't going well, they're a natural part of software development. Go fix them and stop being so emo.

Not the answer you're looking for? Browse other questions tagged or ask your own question.