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?
closed as not constructive by gnat, Kilian Foth, Martijn Pieters, Jalayn, Bryan Oakley Apr 3 '13 at 12:58
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
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.
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.
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.