A developer who understands the problem can use tools to increase productivity and quality. Poor developers don't invest the time or effort to understand how to code properly and avoid defects. They spend their time learning how to use tools without understanding the purpose of the tool or how to use it effectively.
$$$$$ based on providing support for a common problems, such as:
- defect trackers to help you manage defect tracking
- version control systems to manage source code changes
- tools to support Agile development (Version One, JIRA)
- debuggers to help you find defects
Defect TrackersBelieve it or not, some organizations still don't have defect tracking software. I've run into a couple of these companies and you would not believe why. The effect of not having a defect tracking system is pretty severe, and there is evidence to prove this.
- Introducing irrelevant attributes into the defect lifecycle status, i.e. creation of statuses like deferred, won't fix, or functions as designed
- Not being able to figure out if something is fixed or not
- Not understanding who is responsible for addressing a defect
what is a defect? A defect only exists if the code does not behave according to specifications. But what if there are no specifications or the specifications are bad? See It's not a bug, it's... for more information.
Smart organizations understand that the way in which the defect tracker is used will make the biggest difference. Discover how to get more out of you defect tracking system in Bug Tracker Hell and How to Get Out.
Another common problem is that organizations try to manage enhancements and requirements in the defect tracking system. After all whether it is a requirement or a defect it will lead to a code change, so why not put all the information into the defect tracker? Learn why managing requirements and enhancements in the defect tracking system is foolish in Don't manage enhancements in the bug tracker.
Version Control Systemshygiene procedure. If you don't have one then you are likely to catch a pretty serious disease (and at the least convenient time)
Version control is simply chapter 1 of the story. Understanding how to chunk code effectively, integrate with continuous build technology, and making sure that the defects in the defect tracker refers to the correct version are just as important as the choice of version control system.
Tools to support AgileVersion One and JIRA, the simple truth is that using an Agile tool does not make you agile, see this.
These tools are most effective when you actually understand Agile development. One of my most effective Agile implementations only used Google docs in the implementation.
DebuggersI have written extensively about why debuggers are not the best primary tools to track down defects. So I'll try a different approach here. :-)
One of the most enduring sets of ratios in software engineering has been 1:10:100. That is, if the cost of tracking down a defect pre-test (i.e. before QA) is 1, then it will cost 10x if the defect is found by QA, and 100x if the defect is discovered in deployment by your customers. Most debuggers are invoked when the cost function is in the 10x or 100x part of the process.
pre-test defect removal strategies because they cost less and lead to higher code quality. Pre-test defect removal strategies include:
- Planning code, i.e. PSP
- Test driven development, TDD
- Design by Contract (DbC)
- Code inspections
- Pair programming for complex sections of code
Seldom Used ToolsTools that can make a big difference but many developers don't use them:
Important Techniques with No ToolsThere are a number of techniques available in software development that tool vendors have not found a way to monetize on. These techniques tend to be overlooked by most developers, even though they can make a huge difference in productivity and quality.
The Personal Software Process (PSP) and Team Software Process (TSP) were developed by Watts Humphrey, one of the pioneers of building quality software.
The importance of inspections is covered in:
ConclusionThere is definitely a large set of developers that assume that using a tool makes them competent.
The reality is that learning a tool without learning the principles that underlie the problem you are solving is like assuming you can beat the great Michael Jordan at basketball just because you have great running shoes.
Learning tools is not a substitute for learning how do do something competently.
Competent developers are continually learning about techniques that lead to higher productivity and quality, whether or not that technique is supported by a tool.
- Gilb, Tom and Graham, Dorothy. Software Inspections
- 1Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.
- Jones, Capers. The Economics of Software Quality. 2011
- Radice, Ronald A. High Quality
- 2Watts, Humphrey. Introduction to the Personal Software Process
- 3Watts, Humphrey. Introduction to the Team Software Process