Scarab lately, I've also use Bugzilla and GNATS. Each is wonderful and sucks, in its own special way. One thing that has come to mind recently is that I've never actually had any kind of training with any of them. I don't know anybody that has. The knowledge of issue tracking has come from the development culture.
So, I am wondering, what is there that I do not know? What practices and techniques am I missing from simple ignorance?
Speaking with non-developers who've tried to file bugs against projects (as they are always told to do) shows that it is non-intuitive, and most just forget it out of frustration. Often there are rants in open source projects about duplicate bugs that just cause further pain to the users. A look at many sourceforge projects shows that most developers want people to file bugs. Yet they complain that people don't search to see if a condition already exists. The average neophyte (and many experienced alike) are lost at the process of dealing with a bug tracker, let alone trying to find if its already been filed.
Searching amazon find little to nothing on books that cover issue/defect/bug tracking. Searching google finds very little to nothing on tutorials, howtos, or best practices, other than trivial introductions.
We all are using a bug tracking system is important. Yet, knowledge is simply passed from user to user. Where are the tutorials? Where are the getting started guides? Where are the in depth articles for those who are beyond the submit/assign/fix basics? How can we get better at using the tools? How can we help those new to the tools?
Friday, March 16, 2007
Thursday, March 01, 2007
|Mature Developer||Immature Developer|
|Languages||Analyzes the merits and the target domains of programming languages. Knows that a language is just another tool for the toolbox.||Criticizes any language other than the favorite. Common statements, "java sucks...", "ruby sucks..." Often thinks that the favorite language should be the only one used for everything.|
|Dev Environments||Learns to deal with the one at hand, and searches for better ones. If using older systems, this person's .vimrc and .emacsrc files read like a novel. Knows that new dev environments can/should be customized as well.||There can be only one This user promotes their favorite dev environment above all else. They tend to criticize everything else. Often involved in flame wars like VI vs EMACS or Eclipse vs NetBeans|
|Practices||Looks for the areas where a development prectice might be useful. Looks forward to trying out a new practice to conduct a proper evaluation.||Criticizes practices as crazy, cultish, or a waste of time. Doesn't bother to try them because the problems are obvious.|
|Bugs||Starts a binary search through the code to find the source of the problem.||Favorite quote: "I think I've found a bug in the compiler/language/runtime"|
|Builds||Knows how a build comes together. This user has spent time using tools without an IDE and can run the compiler/linker from the command line if required. Instantly knows what's wrong when a dev enviroment shows a build problem.||"My IDE must be broken"|
|Pragmatism||Is it useful?||Does it fit my world view?|