 |
 |
 |
 |
.gif) |
Where is the Accountability for the Quality of the Finished Work?
Software bugs are epidemic. In 2005, the Hudson Bay Company in Canada had software errors in their inventory system that contributed to a $33.3 million loss. In 2004, the UK's Department of Inland Revenue experienced software errors that resulted in a $3.45 billion tax-credit over payment.1 It seems to be happening everywhere-but who or what is to blame?
There are many reasons for software failure: poor project management, the growing complexity of software and market changes. But most often, poor code quality is to blame and whoever developed the software-whether a commercial software vendor, an outside technical vendor or a company's IT organization-is liable.
Corporations may take any financial hit, but development managers are in fact directly responsible for poor application quality. Though their jobs depend on delivering software that is up to spec and that works, many development managers have little insight as to the quality of code their teams are producing.
These managers often report such problems as:
- Developers not conforming to coding and testing standards
- Inability to assess teams' and individual developer's progress and productivity
- Existing tools expose coding errors but not the reasons behind them
- High ongoing maintenance costs
- Projects not meeting customer requirements
- Project deadlines and delivery falling behind schedule
The bottom line is that development managers need to know how their team is doing on an individual developer level because they are fiscally responsible for their team's activities and held accountable for what they produce. The manager must be able to provide actionable steps to correct the course of the application project by better coaching his team.
Development managers are often a promotion away from once having once been a developer. They understand how it feels to think in logical constructs, absolute rights or wrongs, one statement at a time.
But the manager's view must be broader than a set of methods, a new feature or a list of bug fixes. They must coach their development team on the importance of meeting business objectives, the importance of software integrity and code quality. Success or failure in these areas will affect everyone's jobs.
In this day of outsourcing and offshoring, it is also imperative that individual developers take the initiative in improving their skill sets, and take responsibility for the quality of their work.
Managing the Developer
The best developers take a great deal of pride in their work and have a deep sense of ownership. Now consider the standard 80/20 rule, where 20 percent of developers do 80 percent of the work. The 80 percent may be taking the majority of a development manager's time, not to mention company resources-but is that working smart? Even one poorly performing developer can affect the entire team's morale.
How do development managers find out what these people are doing and how they are doing it, without a major, ego-bruising hassle? How can they better understand training needs, reward outstanding performers, apportion a fixed pool for raises, determine who to retain in tough times and break any language barriers?
These questions are especially pertinent for managers who have just taken on a new and unfamiliar development team, and don't have the time to sift through all the code, trying to determine who has done what, trying to gain an insight into abilities and aptitudes.
Developers are likely to resist initiatives that mine data on their work patterns, seeing it as inhibiting their creativity. Performance tracking software, while typical at the project level, has not yet appeared in this context; and is likely to be seen as intrusive-especially the first time a developer is presented with such detailed statistics.
What About Metrics?
Development managers often have a gut-level opinion about the members of their teams. Subjectivity certainly has its place in management. They typically have access to information such as resumes (past experience) and how developers present themselves day-to-day. Software development managers use a wide variety of tools to help them manage their development processes, such as:
- Source control systems
- Static code checking software
- Testing frameworks
- Coverage tools
A well-run source control or change management system helps manage the software's release cycle. It can reduce the risk of application failure, the cost of delivering new or improved application features and the risk of exceeding schedules and budgets. Most developers like the structure provided by a source control system; and a good system will help improve their performance and morale.
This type of system provides some information that can help development managers better understand developer performance, but is it enough?
These systems can answer the following questions:
- Which users made the most changes?
- When were changes made and who made them?
- How many changes were made, by user, date or file?
- What has a specified user done in the last 24 hours?
- How many files/which files does a specified user have open?
- How many bugs were reported in the last four quarters?
- Important unanswered questions remain, however such as:
- What is the resulting code quality of the changed code?
- Was it unit tested?
- Who wrote the most code last week, month or year?
- What changed between the current build and the last?
- What types of errors were found in each version?
- Have the number and types of bug improved since the last release?
Code checker tools help developers adhere to coding standards. They point to lines of code within files and offer details on how to adhere to the standards. Some code checkers document possible security violations and provide links to the code that causes the violations.
Ideally, development managers should be able run code checkers against all the code in their repository at one time, to help them gain a global view so that they can track for improvements.
Correlating file ownership with coding standards violations would allow development managers to determine at a glance who created the greatest (or least) number of violations. Seeing this information on a graph would help development managers understand trends, with the goal of overall quality improvement.
Testing Frameworks
All programmers understand the need to test their own code, but few take the time or make it a priority to test early in the application development cycle. The result is a vicious cycle of few tests, poor-quality code and an increasing
amount of debugging work.
Testing frameworks let them write tests before their code is written. They can explicitly declare the expected results of a specific program execution before they write the code. Then they write the code, test it using the framework and change the code until it meets the expected results. With framework software, developers get immediate feedback from writing, saving and rerunning their own unit tests.
Framework software provides an iterative process that collects tests cumulatively over the lifespan of the software. As the software changes to meet user needs, so do the test cases within the framework. Using a testing framework increases programmer productivity and program stability, while reducing debugging time and stress.
When developers use a testing framework, development managers can determine:
- The number of test cases
- Number of tests run
- Number of failures (anticipated)
- Number of errors (unanticipated)
Coverage Software
Having a test framework in place is good practice, however, this can only tell management which tests have passed or failed. Using unit tests alone does not ensure all paths or functionalities in the code base are tested. Coverage software tells developers how much of their code is covered by unit tests. Ideally, development managers should be able to plot code coverage over time per developer as it relates it to improved code quality and ensures that every line of executable code is tested at some level.
|
|
|
|
|
|
 |
|
|
