|
|
A Recipe for Great Software Quality
Posted On November 1, 2007 by Rose Mary filed under Miscellaneous
1. Use Source Control
Many developers, we know, are not really aware what source control is. Source control essentially makes sure that a file's source doesn't get changed improperly. This includes making sure everyone is using the latest version of the file, and that no two people are editing it at the same time, resulting in overwritten changes. You must also ensure that the files aren't deleted, moved, or otherwise manipulated in a way that would leave editors scratching their heads.
Typical source control methods use a system of checking files in and out, somewhat akin to a library system. If a file is checked out, then no one else should be able to use or edit that file, until it is checked back in.. Note, however, that anyone may still view the file at any time.
This process ensures that no two people will ever edit the same file simultaneously. Also, by making sure that everyone checks files out properly through the application, no changes will ever be overwritten - unless done on purpose.
There are a number of commercial packages, and the most popular among Indian companies is Visual SourceSafe. However, for the newbies as well as open source/Free software worshippers, there is CVS, which is free. Please check out CVS in the Developer IQ CD.
2. Organise a database
The old idiom says that you need to learn from your mistakes. Unfortunately, while developing a product, or completing a project, developers involved commit a huge volume of mistakes (bugs in code). This is a natural part of the process. But unless you remember the bugs, which have occurred and then correct them, there is no way you can ship the product on time.
If you are developing code, even in a small team, without an organised database listing all the known bugs in the code, you are going to ship low quality code.
Large companies like Microsoft employ staff who maintain databases of all known bugs while a product is being developed. Despite this we get enough chances to blame the software giant for producing buggy software. Imagine what it must be like for those companies that don't have people creating and maintaining bug lists.
Bug databases can be complicated as well as simple. A useful bug database must include the following data for every bug, at the least:
· complete steps to reproduce the bug
· expected behaviour
· observed (buggy) behaviour
· who it's assigned to
· whether it has been fixed or not
It shouldn't be tough for you to create a small table using Excel or your favourite spreadsheet and list these details.
3. Bug Tracking System
Bug tracking is a process that does not stop at the end of product or project development completion. Many times, it starts there. A development team needs to have an effective bug tracking system.
When you are into Web development, you can ask users (surfers or readers) to report a missing link or errors. Bug tracking in Web-based systems is easier mainly because of the interactive nature of the Internet.
Most development companies have an Internet-based bug tracking system for their products. We also recommend you take a look at the bug tracking system of KDE, at bugs.kde.org as a classic example of bug tracking web site.
Joel Spolsky, legendary programmer and author, has kindly permitted us to reproduce his tips for effective bug tracking:
Top 10 Tips for Bug Tracking
1. A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug.
2. Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what he saw is fixed.
3. There are many ways to resolve a bug. FogBUGZ allows you to resolve a bug as fixed, won't fix, postponed, not repro, duplicate, or by design.
iv. Not Repro means that nobody could ever reproduce the bug. Programmers often use this when the bug report is missing the repro steps.
4. You'll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number so that the poor tester doesn't have to re-test the bug on a version of the software where it wasn't even supposed to be fixed.
5. If you're a programmer, and you're having trouble getting testers to use the bug database, don't accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: "please put this in the bug database. I can't keep track of emails."
6. If you're a tester, and you're having trouble getting programmers to use the bug database, just don't tell them about bugs - put them in the database and let the database email them.
7. If you're a programmer, and only some of your colleagues use the bug database, just start assigning them bugs in the database. Eventually they'll get the hint.
8. If you're a manager, and nobody seems to be using the bug database that you installed at great expense, start assigning new features to people using bugs. A bug database is also a great "unimplemented feature" database.
9. Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what percentage of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas.
If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more.
8 For the bug database to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will go around the bug database. [Joel Spolksy- On Bug Tracking, 2000]
4. Update Schedules
We sometimes compare producing this magazine to that of a software project. In fact, the process is not very different. The editor assigns writers with the tasks on articles, the CD team with the content which needs to be sourced or created.
What happens sometimes is that our writers don't deliver articles on time. This results in the pages getting delayed which, in turn, results in the design team doing a hotchpotch job, and even after all this, the schedule at the printer goes awry. The end result is that the magazine hits the stands later than the competition (but, fortunately or unfortunately, we don't have competition).
This applies to software coding too. Developers need to stick to deadlines. The best way to do that is to stick to a basic plan of action and schedule. Planning has to be careful. Over-commitment due to an overzealous mood can lead to things going topsy-turvy, resulting in both finances and reputation taking a hit.
Experts' Tips on Scheduling
1. Unless the project size is too large and the processes complex, keep the scheduling simple. In case you are following any of the so-called standards like ISO or SECIM, stick to their guidelines.
2. The scheduling should be a collective decision, and should be a bottom-up approach, rather than having the project leaders dictating terms. It will be ideal if the programmer can comment on the schedule, with his supervisor holding fort, as far as possible.
3. Add enough buffer time to each task in schedule.
Plan for holidays, power breakd-owns, virus attacks and the software team's ill-health.
Cut down each sub-schedule into multiple tasks. Some of the best project leaders go to the extent of tracking schedules down to hours and to steps like multiple software builds in a day.
6. Creating Specs
Developers make for very bad documenters (we learned that the hard way when we hired some hard-core programmers to write)! This is the biggest problem with most deve-lopers, as the development work created by one developer sometimes is Greek or Latin to another. As a result, when teams consisting solely of programmers attack a problem, they prefer to express their solution in code, rather than in documents. They would much rather dive in and write code than produce a spec first.
At the design stage, when you dis-cover problems, you can fix them easily by editing a few lines of text or by re-arranging the flow chart. However, once the code is written, it is very difficult to change it. Many software development compa-nies have dedicated technical writers who actually get involved in writing specs and not just manuals. And, some hardcore programmers do tend to complain that a less qualified developer actually gets promoted, because he has better English language skills. That may or may not be true, but it indicates that writing good specs is as important as writing great code.
7. Invest in Testers
This advice does not apply to only large software houses. The success of large software houses like Infosys depends on the fact that they are able to implement quality projects on time. And, these companies have a number of designated Software Testers. In fact, software guru Ralph Peter Mendelson suggests that for every three programmers, there has to be at least one tester.
That equation may differ from c8ompany to company, or project to project, but the mantra remains that a programmer cannot test the code, which he or she may have written efficiently. So invest in testers and the more in this case is better (and definitely merrier on the longer run).
Many developers, we know, are not really aware what source control is. Source control essentially makes sure that a file's source doesn't get changed improperly. This includes making sure everyone is using the latest version of the file, and that no two people are editing it at the same time, resulting in overwritten changes. You must also ensure that the files aren't deleted, moved, or otherwise manipulated in a way that would leave editors scratching their heads.
Typical source control methods use a system of checking files in and out, somewhat akin to a library system. If a file is checked out, then no one else should be able to use or edit that file, until it is checked back in.. Note, however, that anyone may still view the file at any time.
This process ensures that no two people will ever edit the same file simultaneously. Also, by making sure that everyone checks files out properly through the application, no changes will ever be overwritten - unless done on purpose.
There are a number of commercial packages, and the most popular among Indian companies is Visual SourceSafe. However, for the newbies as well as open source/Free software worshippers, there is CVS, which is free. Please check out CVS in the Developer IQ CD.
2. Organise a database
The old idiom says that you need to learn from your mistakes. Unfortunately, while developing a product, or completing a project, developers involved commit a huge volume of mistakes (bugs in code). This is a natural part of the process. But unless you remember the bugs, which have occurred and then correct them, there is no way you can ship the product on time.
If you are developing code, even in a small team, without an organised database listing all the known bugs in the code, you are going to ship low quality code.
Large companies like Microsoft employ staff who maintain databases of all known bugs while a product is being developed. Despite this we get enough chances to blame the software giant for producing buggy software. Imagine what it must be like for those companies that don't have people creating and maintaining bug lists.
Bug databases can be complicated as well as simple. A useful bug database must include the following data for every bug, at the least:
· complete steps to reproduce the bug
· expected behaviour
· observed (buggy) behaviour
· who it's assigned to
· whether it has been fixed or not
It shouldn't be tough for you to create a small table using Excel or your favourite spreadsheet and list these details.
3. Bug Tracking System
Bug tracking is a process that does not stop at the end of product or project development completion. Many times, it starts there. A development team needs to have an effective bug tracking system.
When you are into Web development, you can ask users (surfers or readers) to report a missing link or errors. Bug tracking in Web-based systems is easier mainly because of the interactive nature of the Internet.
Most development companies have an Internet-based bug tracking system for their products. We also recommend you take a look at the bug tracking system of KDE, at bugs.kde.org as a classic example of bug tracking web site.
Joel Spolsky, legendary programmer and author, has kindly permitted us to reproduce his tips for effective bug tracking:
Top 10 Tips for Bug Tracking
1. A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug.
2. Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what he saw is fixed.
3. There are many ways to resolve a bug. FogBUGZ allows you to resolve a bug as fixed, won't fix, postponed, not repro, duplicate, or by design.
iv. Not Repro means that nobody could ever reproduce the bug. Programmers often use this when the bug report is missing the repro steps.
4. You'll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number so that the poor tester doesn't have to re-test the bug on a version of the software where it wasn't even supposed to be fixed.
5. If you're a programmer, and you're having trouble getting testers to use the bug database, don't accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: "please put this in the bug database. I can't keep track of emails."
6. If you're a tester, and you're having trouble getting programmers to use the bug database, just don't tell them about bugs - put them in the database and let the database email them.
7. If you're a programmer, and only some of your colleagues use the bug database, just start assigning them bugs in the database. Eventually they'll get the hint.
8. If you're a manager, and nobody seems to be using the bug database that you installed at great expense, start assigning new features to people using bugs. A bug database is also a great "unimplemented feature" database.
9. Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what percentage of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas.
If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more.
8 For the bug database to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will go around the bug database. [Joel Spolksy- On Bug Tracking, 2000]
4. Update Schedules
We sometimes compare producing this magazine to that of a software project. In fact, the process is not very different. The editor assigns writers with the tasks on articles, the CD team with the content which needs to be sourced or created.
What happens sometimes is that our writers don't deliver articles on time. This results in the pages getting delayed which, in turn, results in the design team doing a hotchpotch job, and even after all this, the schedule at the printer goes awry. The end result is that the magazine hits the stands later than the competition (but, fortunately or unfortunately, we don't have competition).
This applies to software coding too. Developers need to stick to deadlines. The best way to do that is to stick to a basic plan of action and schedule. Planning has to be careful. Over-commitment due to an overzealous mood can lead to things going topsy-turvy, resulting in both finances and reputation taking a hit.
Experts' Tips on Scheduling
1. Unless the project size is too large and the processes complex, keep the scheduling simple. In case you are following any of the so-called standards like ISO or SECIM, stick to their guidelines.
2. The scheduling should be a collective decision, and should be a bottom-up approach, rather than having the project leaders dictating terms. It will be ideal if the programmer can comment on the schedule, with his supervisor holding fort, as far as possible.
3. Add enough buffer time to each task in schedule.
Plan for holidays, power breakd-owns, virus attacks and the software team's ill-health.
Cut down each sub-schedule into multiple tasks. Some of the best project leaders go to the extent of tracking schedules down to hours and to steps like multiple software builds in a day.
6. Creating Specs
Developers make for very bad documenters (we learned that the hard way when we hired some hard-core programmers to write)! This is the biggest problem with most deve-lopers, as the development work created by one developer sometimes is Greek or Latin to another. As a result, when teams consisting solely of programmers attack a problem, they prefer to express their solution in code, rather than in documents. They would much rather dive in and write code than produce a spec first.
At the design stage, when you dis-cover problems, you can fix them easily by editing a few lines of text or by re-arranging the flow chart. However, once the code is written, it is very difficult to change it. Many software development compa-nies have dedicated technical writers who actually get involved in writing specs and not just manuals. And, some hardcore programmers do tend to complain that a less qualified developer actually gets promoted, because he has better English language skills. That may or may not be true, but it indicates that writing good specs is as important as writing great code.
7. Invest in Testers
This advice does not apply to only large software houses. The success of large software houses like Infosys depends on the fact that they are able to implement quality projects on time. And, these companies have a number of designated Software Testers. In fact, software guru Ralph Peter Mendelson suggests that for every three programmers, there has to be at least one tester.
That equation may differ from c8ompany to company, or project to project, but the mantra remains that a programmer cannot test the code, which he or she may have written efficiently. So invest in testers and the more in this case is better (and definitely merrier on the longer run).