Related
I would need your help. I've come across an interesting book - Programming the Cell Processor: For Games, Graphics, and Computation - it contains mostly C and some Assembly for Cell. The technology is interesting indeed, but there are some doubts on my side.
The book is from 2008 and some things has changed:
There is no Linux support on current firmware version.
Last version on IBM's website is from 2008 Red Hat Enterprise 5.2 and Fedora 9 - has anyone an experience running this IBM SDK on Fedora 13 or at least any version higher than stated Fedora 9, and is Linux available of sufficient testing?
Would it be useful for example for creation of distributable PSN game, and if anyone knows anything about price to actualy get a product there (as I've heard that it waaaaay more expensive than for example X-box indie games)
So do you think that it is worth it or not? Be it just for education purposes or something "more" serious?
Any thoughts are welcomed, thank you!
Cell was dumped by IBM for general purpose computers. It will live for the next 5 years in the Playstation and i'm pretty sure that the next generation Playstation - whenever it will be ready - will also use Cell again because establishing something new in CPU land is so unaffordable today.
But as a technolgy it is indeed no longer interested. Learning CUDA might be a better choice.
Given that you don't have access to a Cell machine, I'd advise that it's probably not worth it. I absolutely love the Cell architecture - I think it was a fantastic step in the right direction. Unfortunately, having done some Cell development in the past, I was really disappointed with the tool chain, the simulator and the seemingly hostile attitude taken towards developers recently.
So given that you're not going to be able to use a real Cell machine in order to get the speed gains you would get from writing programs within that idiom, you'd probably be much better off looking into general distributed programming techniques (using MPI or something similar). These skills are going to be readily transferrable to the Cell or its derivatives, or any similar architectures that might arise in the future.
As far as I'm concerned, and as much as it pains me, I think the Cell is basically a developmental dead end unless you have access to a commercial development license, you'll be extremely frustrated in your ability to actually get anything out of the architecture.
I am the lone software engineer on a team that develops physics models (approx 30,000 lines of code). The rest of the team consists of scientists who have been developing their codebases for about 20 years. My workflow goes something like this:
Scientist requests a new feature
I implement it
Via testing & validation, I find a serious problem somewhere deep within the numerics
Scientist requests a new feature (without fixing the problems identified in #3)
Our problem seems to be that bug tracking is done via e-mail and post-it notes. Busy work schedules let bugs slip under the radar for months and months. I think some formalized bug tracker (i.e. Trac, Redmine, Jira, FogBugz, etc.) could help us. The following features are essential:
Incredibly easy to use
Integrate with version control software (we use Subversion)
There are plenty of posts that suggest which bugtracker is "best"... but I suppose that I am more interested in:
What's your experience in whether or not the overhead of a bugtracker is worth it
How do you convince a physicist (who follows poor software engineering "best practices" from the 70's) that a bug tracker is worth the extra effor?
I get the feeling that if I install a bug tracker, I'll be the sole user. Has anyone else experienced this? Is it still useful? It seems like the team would need a certain amount of "buy-in" to make a bug tracker worth the additional overhead.
Bug trackers are definitely worth it, in part because they formalize the work-flow required to implement new features and fix bugs. You always have a central place for your work load ("My bugs", "My tasks", etc). Pretty much every environment that I've worked at in the last few years has had a bugtracker of some sort so I'm not sure what to recommend in terms of buy in. Do you have more than one scientist coming to you for feature requests/bug fixes? If so, then perhaps you could use the bug tracker as a conflict resolution system of sorts. Do you have a boss/manager? Then having a bug tracking system would provide a lot of insight for your boss.
In general, as a software developer, bug trackers have been very useful. My suggestion would be to think of ways that a bugtracker would enhance your & your coworker's life. Maybe do a quick demo.
HTH.
In my experience, the overhead of a bugtracker is noticeable but definitely worth it! The catch is that if you decide to use a bug tracker, it can only succeed if everyone uses it. Being the sole user of such a system is not quite as useful.
Having said that, even if I am the sole user (which tends to happen a lot), I still install the bugtracker (typically trac). If you use it religiously (enter every thing that comes in through different means as a bug and ALWAYS refer to bug# in your replies), the team generally tends to pick it up over time.
Enter milestones (or whatever your tracker of choice calls them) and link bugs to them. Whenever someone asks what the progress of something is, call up the milestone report or equivalent and SHOW THEM. This helps convert people from thinking of the bug tracker as a nuisance to realizing that it can be a source of invaluable information.
I suggest taking a look at Strategy 2 in this Joel On Software article. He basically argues that if your company doesn't use bug tracking software, you should just start using it for yourself, and demonstrate how it helps get things done. Also ask other people to use it to submit bugs so they see how easy it is to use.
Even if you're the sole user (it happened to me once), it's worth it. You can start saying things like, "Bug 1002 is blocking. Who can help me with that so we can move on to this and that feature."
We found redmine to be a better than trac simply because it is easier to use. It does lack some of the features found in some of the other systems, but this also means there is less stuff for non-programmers to have a problem with. It's also very nice because it allows someone other than the programmers to get a feel for the current state of the system. If there is a large number of critical unclosed bugs it is easier to make people understand that their requested feature will have to wait a little.
This is a similar question.
What's the Most Effective Workflow Between People Who Develop Algorithsm and Developers?
It does NOT speak to which bugtracker is best, but it does speak to how to convince the physicists to buy-in.
Using subversion? Here's a /. post that is helpful:
Best Integrated Issue-Tracker For Subversion?
An in general, here's a Comparison of Issue Tracking Systems.
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.
Closed 9 years ago.
As the title says, I'm starting one project right now, and trying to layout the infrastructure for the project (SVN, Email, Bug tracking, Online Forums, etc...)
So, Bugzilla or Mantis?
I think you'll find that your team will like either Trac or Redmine more than Bugzilla or Mantis. Both integrate nicely with Subversion. Both include wiki, forums, project management features...
Quick overview:
Trac: Very widely used and loved, written in python, huge community, lots of "plugins". A common complaint is that it doesn't support multiple projects out-of-the-box, but you can add a plugin to help with that.
Redmine: Written in RubyOnRails. Like Trac, but more complete out of the box. The authors of Redmine are trying to create a better Trac than Trac.
If you are interested in what others searching for bug trackers have written, comparing trackers to each other, I've put some links together here:
http://ifdefined.com/blog/post/2007/10/Links-to-other-comparisons-of-issue-trackers.aspx
If you on Windows, which I'm guessing you aren't, then also consider BugTracker.NET, an easy-to-use, very configurable bug tracking system in .NET/MS SQL Server. (Disclaimer: I'm the author).
I like mantis. It's simple and it gets the job done.
I've used Bugzilla and Mantis, but I prefer Mantis' simplicity. It's not as feature rich as Bugzilla but, I remember fighting with Bugzilla a lot more. Mantis is the kind of thing you can setup once then leave.
Mantis definitely wins on usability grounds over Bugzilla.
In particular, it is just a lot faster to log bugs on Mantis. Time to log bugs is a blocker for some people - I've heard it used as an excuse for not logging them, fixing them and pretending there was never a bug to fix (symptomatic of deeper team problems).
It wasn't until a client (currently using Basecamp, bleah!) canned the idea of Mantis because it wasn't pretty enough that I realised some people (as noted above) think it is ugly.
Compared to Bugzilla or another system we tried implementing, some weird European thing, Mantis is gorgeous.
I know Mantis scales well - a friend used it for the production of the movie Happy Feet. He customised it by adding one extra field to provide another level of categorisation.
Bugzilla is bigger, a larger community, more features, more power ... for that reason I've always prefered mantis ;) Mantis is as ugly as sin but for most projects it gives you what you need in a simple and intuative way.
If you have a large team, a big QA department and all the rest bugzillia may be a better fit. Small team that just needs to get stuff done - then mantis is probably better in my opinion.
The biggest feature missing from mantis (they may have added it since, this was a few years ago) is the reports feature so you can track progress with nice line and pie charts. However, I just wrote a simple PHP script to pull out the data and manually created them in Excel each week (only took 5 minutes or so). Not great but functionally sufficient for what we needed at the time.
However there online demos of both so I suggest you try them out and pick what suits you the best.
Mantis is great and very easy to setup
I have been using it for about 3 years
It has the following problems.
There is a 2 Meg limit on the file size that you can store in issue. This becomes a problem when you want to include screen shots of the problem.
If two people update the issue at the same time - Someone will lose data
I have used both and didn't like them at all, I prefer Trac, thou if you really need to choose between those two I'd go for Bugzilla
The integration for TRAC with subversion is real good (have a look at Assembla to see how the integration works )
Trac is also open source and its pretty simple to add new reports and stuff like that.
Mantis is great and simple,
simplicity is important as my clients are non technical people.
You could try Redmine. It gives you repo access, trackers, forums, wiki, calendar - in one place.
I have extensively used Bugzilla (default for projects at work) but Mantis gets my vote for easy setup and use.
I've heard good things about fogbugz but have yet to find an opportunity to use it.
http://www.fogcreek.com/FogBUGZ/
I prefer mantis. It performs nicely and is easily extend able either by the use of plugins or with by coding.
Another vote for Trac -- dead simple to get going, nice web-based view into your repository, etc.
Choosing the right bug tracker requires that you know who is going to use it (and how it is going to be used). I've used Bugzilla and Mantis and found Bugzilla better from a technical point of view but Mantis wins if some of your bug reporters are not programmers / not programmer minded. Its interface is less 'threatening' for a novice bugtracker user.
If you are going to have a private bugtracker you also need to consider the options it gives you to specify who is allowed to view/edit etc.
I've used bugzilla for a while, but Redmine get my vote. easy setup, very very intuitive.
Recently I've been doing lots of weekend coding, and have began to really need a bugtracker as things are gaining speed. This is probably the worst case scenario because I basically have to let things cool down over the week,so I simply can't remember the bugs in my head. So far I've been using a text file to jot down bugs,but I'd rather use something a bit better.
The biggest points here are ease of use and very little setup time.Don't want to spend more than an hour learning the basics and trying to install something. Also in my case I'm on a Mac so that would help, but solutions for other platforms are welcomed as they will likely help others.
FogBugz has a student/startup edition that's free indefinitely, for 2 or less users.
Personally, I use Excel. (Wait, come back, I'm not crazy!) For a bigger / team project, I've gotten a ton of mileage out of Bugzilla, but that tends to be kind of overkill for a one-person project.
But, a well-organized spreadsheet, with columns for things like "status", "description", "code module", "resolved date," etc, gets you pretty close to what you'd need for a small project. Sorting a spreadsheet by column isn't anywhere near a search, but its a whole lot better than "find in text file."
Heck, if you use Google docs rather than excel, you can even publish the thing as an RSS feed and get it anywhere.
And, the major advantage is that the setup time and learning curve are both effectively nil.
Addendum: And of course, the instant your "One-Person Bug Tracker" becomes a "Two-Person Bug Tracker" you must switch to something better. Bugzilla, FogBugz, anything. Trust me, I've been there.
Trac or Redmine are both pretty good. I don't know how easy they are to set up on a Mac.
It's worth mentioning that FogBugz also has a free version for up to 2 users, which would suit you. It is hosted so there is no installation and you can use something like Fluid to access it in its own window.
I don't think you need a full blown bugtracker for your scenario.
Try tiddly wiki, store each bug in a tiddler and give them tags like 'open' or 'closed'.
There is no installation required (only one html file), and it's very easy to use.
And platform neutral.
If you're working on a LAMPP stack, then for ease of setup and use I would probably recommend Mantis. It's written in PHP / MySQL and the only installation involved was specifying where the database should be created and what credentials should be used.
Oh, and its FOSS.
I would suggest Omnigroup's Omnifocus - it's an excellent task tracker, and if you just make the mental leap from bug to task, I think it works famously for one man projects as well as being an excellent way to organize your no doubt burgeoning task queue.
Eclipse has a really interesting system--I don't know why so few people seem to know about it.
It's tied in with their to-do list. It gives you the ability to enter bugs with as much or as little info as you like. You can tie it to versioning or an external bug tracker if you like. It's a decent bug tracker in itself.
The real trick is how it works with your source code.
Before you begin work you select a bug from the list. All the time you're coding, it tracks what files you are editing. It can close old tabs for you, and will also highlight areas of the source tree that you have modified a lot.
The nice thing is, you can go back to any bug you've edited an you will get your "Environment" back. Not only all your notes and stuff, but the same tabs will open up and the same sections of code in the navigator will be highlighted.
Also eclipse works with virtually any language, it's not just restricted to Java...
let me put in a good word for ditz - it's a bit bare-bones, but it has the invaluable feature that bugs are checked into your repository. it's also very easy to use once you get used to its way of doing things
You can use fogbugz for free if you're a one man team.
It's super easy to use and quick to learn.
They made it so that bugs are really easy to enter, no mandatory fields.
I'm the author of BugTracker.NET mentioned in another post. If I were looking for a tracker for JUST ONE PERSON with MINIMUM hassle, I'd use FogBugz, because it's hosted. No installation, no need to worry about backups.
But, what are you doing about version control? Don't you have to worry about that too, and backing that up? If so, consider something like Unfuddle or CVSDude where you can get BOTH Subversion and Trac, or Subversion and Fogbugz.
I use Mantis at home and I'm happy with it. It can be a pain in the arse to get it working so you can choose to download a free and ready-made VM installation. Cannot be easier than that,
Maybe a spreadsheet would be the next logical step? I know it sounds really un-sexy, but if you're the only user, you don't have to worry much about others mucking it up, and it adds a few basic features over a text file like sorting. Then if you later need to graduate to something RDBMS-backed, you would likely have a feasible import path. I just know that for me, when working by myself, I don't tend to get around to putting bugs in anything that requires more care and feeding than that (of course when working with others the collaborative needs make a more defined repository a requirement, but that's a different story).
EDIT: After noting the availability of free, hosted access to FogBugz, I'm re-thinking the bar for care and feeding...
RT from BestPractical is great.
I also get a lot of mileage out of just keeping a list of items in a text file with vi, if I can express them all in one line. This is usually for many small todo items on a single component or task.
I've tried bugtracker.net and even though it's a little bit rough on the edges, it's free and was built with ASP.NET:
http://sourceforge.net/project/showfiles.php?group_id=66812
Are you using a source control repository as well? If not, you really should, even though you're only a one-man team.
My personal preference is to use a VMWare Virutal Application (free) that offers no-hassle setup gives you access to both Trac and Subversion. You can find many different virual appliances through searching. Here is one example of getting a Trac/SVN virtual appliance up and running:
http://www.rungeek.com/blog/archives/how-to-setup-svn-and-trac-with-a-virtual-appliance/
Trac is an excellent project management tool that sports a bug tracker, wiki, and integrated source control management. It's adaptable to your needs, and fits me very well personally.
I use bugzilla for this purpose. Plus for me was that it has integration with Eclipse (precisely with Mylyn). FogBuzz has it to but AFAIK it is nonfree.
Plus it sits on my laptop so I can code and add/remove bugs when offline (it was biggest disadvantage of hosted solutions for me)
Installation was not a problem in Ubuntu (and any debian-based distro I suppose).
I dig ELOG in those cases, it's more of a personal blog, but it's easy to handle and install, the data is local on your computer and you can search all entries via fulltext. Always sufficed for me.
If you have a Windows box with IIS and MSSQL (including SQL Server Express), you should look at Bugtracker.net. It is free and open source (you get the source code), and it is extensible.
Even if you are a one man shop, having a free bug tracking system with this much power will allow you to grow over time, because it is fairly easy to add future users into the system.
You can also customize it for the look of your organization, business or product.
Ontime 2008 by Axosoft is free for a single user licence. It's industrial strength and will give you alot more that just bug tracking!
http://www.axosoft.com
Jira which now has free personal licenses.
I am using leo for this purpose. To be more specific, its cleo plugin.
Of course you might need to spend some time to get used to leo, but it will pay off.
A flat text file is just a list, an Excel spreadsheet is a two-dimensional list.
leo lets you keep the data in a tree! And it also has clones.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Several times now I've been faced with plans from a team that wants to build their own bug tracking system - Not as a product, but as an internal tool.
The arguments I've heard in favous are usually along the lines of :
Wanting to 'eat our own dog food' in terms of some internally built web framework
Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way
Believing that it isn't difficult to build a bug tracking system
What arguments might you use to support buying an existing bug tracking system? In particular, what features sound easy but turn out hard to implement, or are difficult and important but often overlooked?
First, look at these Ohloh metrics:
Trac: 44 KLoC, 10 Person Years, $577,003
Bugzilla: 54 KLoC, 13 Person Years, $714,437
Redmine: 171 KLoC, 44 Person Years, $2,400,723
Mantis: 182 KLoC, 47 Person Years, $2,562,978
What do we learn from these numbers? We learn that building Yet Another Bug Tracker is a great way to waste resources!
So here are my reasons to build your own internal bug tracking system:
You need to neutralize all the bozocoders for a decade or two.
You need to flush some money to avoid budget reduction next year.
Otherwise don't.
I would want to turn the question around. WHY on earth would you want to build your own?
If you need some extra fields, go with an existing package that can be modified.
Special report? Tap into the database and make it.
Believing that it isn't difficult? Try then. Spec it up, and see the list of features and hours grow. Then after the list is complete, try to find an existing package that can be modified before you implement your own.
In short, don't reinvent the wheel when another one just needs some tweaking to fit.
Programmers like to build their own ticket system because, having seen and used dozens of them, they know everything about it. That way they can stay in the comfort zone.
It's like checking out a new restaurant: it might be rewarding, but it carries a risk. Better to order pizza again.
There's also a great fact of decision making buried in there: there are always two reasons to do something: a good one and the right one. We make a decision ("Build our own"), then justify it ("we need full control"). Most people aren't even aware of their true motivation.
To change their minds, you have to attack the real reason, not the justification.
Not Invented Here syndrome!
Build your own bug tracker? Why not build your own mail client, project management tool, etc.
As Omer van Kloeten says elsewhere, pay now or pay later.
There is a third option, neither buy nor build. There are piles of good free ones out there.
For example:
Bugzilla
Trac
Rolling your own bug tracker for any use other than learning is not a good use of time.
Other links:
Three free bug-tracking tools
Comparison of issue tracking systems
I would just say it's a matter of money - buying a finished product you know is good for you (and sometimes not even buying if it's free) is better than having to go and develop one on your own. It's a simple game of pay now vs. pay later.
First, against the arguments in favor of building your own:
Wanting to 'eat our own dog food' in terms of some internally built web framework
That of course raises the question why build your own web framework. Just like there are many worthy free bug trackers out there, there are many worthy frameworks too. I wonder whether your developers have their priorities straight? Who's doing the work that makes your company actual money?
OK, if they must build a framework, let it evolve organically from the process of building the actual software your business uses to make money.
Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way
As others have said, grab one of the many fine open source trackers and tweak it.
Believing that it isn't difficult to build a bug tracking system
Well, I wrote the first version of my BugTracker.NET in just a couple of weeks, starting with no prior C# knowledge. But now, 6 years and a couple thousand hours later, there's still a big list of undone feature requests, so it all depends on what you want a bug tracking system to do. How much email integration, source control integration, permissions, workflow, time tracking, schedule estimation, etc. A bug tracker can be a major, major application.
What arguments might you use to support buying an existing bug tracking system?
Don't need to buy.Too many good open source ones: Trac, Mantis_Bug_Tracker, my own BugTracker.NET, to name a few.
In particular, what features sound easy but turn out hard to implement, or are difficult and important but often overlooked?
If you are creating it just for yourselves, then you can take a lot of shortcuts, because you can hard-wire things. If you are building it for lots of different users, in lots of different scenarios, then it's the support for configurability that is hard. Configurable workflow, custom fields, and permissions.
I think two features that a good bug tracker must have, that both FogBugz and BugTracker.NET have, are 1) integration of both incoming and outgoing email, so that the entire conversation about a bug lives with the bug and not in a separate email thread, and 2) a utility for turning a screenshot into a bug post with a just a couple of clicks.
The most basic argument for me would be the time loss. I doubt it could be completed in less than a month or two. Why spend the time when there are soooo many good bug tracking systems available? Give me an example of a feature that you have to tweak and is not readily available.
I think a good bug tracking system has to reflect your development process. A very custom development process is inherently bad for a company/team. Most agile practices favor Scrum or these kinds of things, and most bug tracking systems are in line with such suggestions and methods. Don't get too bureaucratic about this.
A bug tracking system can be a great project to start junior developers on. It's a fairly simple system that you can use to train them in your coding conventions and so forth. Getting junior developers to build such a system is relatively cheap and they can make their mistakes on something a customer will not see.
If it's junk you can just throw it away but you can give them a feeling of there work already being important to the company if it is used. You can't put a cost on a junior developer being able to experience the full life cycle and all the opportunities for knowledge transfer that such a project will bring.
We have done this here. We wrote our first one over 10 years ago. We then upgraded it to use web services, more as a way to learn the technology. The main reason we did this originally was that we wanted a bug tracking system that also produced version history reports and a few other features that we could not find in commercial products.
We are now looking at bug tracking systems again and are seriously considering migrating to Mantis and using Mantis Connect to add additional custom features of our own. The amount of effort in rolling our own system is just too great.
I guess we should also be looking at FogBugz :-)
Most importantly, where will you submit the bugs for your bug tracker before it's finished?
But seriously. The tools already exist, there's no need to reinvent the wheel. Modifying tracking tools to add certain specific features is one thing (I've modified Trac before)... rewriting one is just silly.
The most important thing you can point out is that if all they want to do is add a couple of specialized reports, it doesn't require a ground-up solution. And besides, the LAST place "your homebrew solution" matters is for internal tools. Who cares what you're using internally if it's getting the job done as you need it?
Being a programmer working on an already critical (or least, important) task, should not let yourself deviate by trying to develop something that is already available in the market (open source or commercial).
You will now try to create a bug tracking system to keep track of the bug tracking system that you use to track bugs in your core development.
First:
1. Choose the platform your bug system would run on (Java, PHP, Windows, Linux etc.)
2. Try finding open source tools that are available (by open source, I mean both commercial and free tools) on the platform you chose
3. Spend minimum time to try to customize to your need. If possible, don't waste time in customising at all
For an enterprise development team, we started using JIRA. We wanted some extra reports, SSO login, etc. JIRA was capable of it, and we could extend it using the already available plugin. Since the code was given part of paid-support, we only spent minimal time on writing the custom plugin for login.
Building on what other people have said, rather than just download a free / open source one. How about download it, then modify it entirely for your own needs? I know I've been required to do that in the past. I took an installation of Bugzilla and then modified it to support regression testing and test reporting (this was many years ago).
Don't reinvent the wheel unless you're convinced you can build a rounder wheel.
I'd say one of the biggest stumbling blocks would be agonising over the data model / workflow. I predict this will take a long time and involve many arguments about what should happen to a bug under certain circumstances, what really constitutes a bug, etc. Rather than spend months arguing to-and-fro, if you were to just roll out a pre-built system, most people will learn how to use it and make the best of it, no matter what decisions are already fixed. Choose something open-source, and you can always tweak it later if need be - that will be much quicker than rolling your own from scratch.
At this point, without a large new direction in bug tracking/ticketing, it would simply be re-inventing the wheel. Which seems to be what everyone else thinks, generally.
Your discussions will start with what consitutes a bug and evolve into what workflow to apply and end up with a massive argument about how to manage software engineering projects. Do you really want that? :-) Nah, thought not - go and buy one!
Most developers think that they have some unique powers that no one else has and therefore they can create a system that is unique in some way.
99% of them are wrong.
What are the chances that your company has employees in the 1%?
I have been on both sides of this debate so let me be a little two faced here.
When I was younger, I pushed to build our own bug tracking system. I just highlighted all of the things that the off the shelf stuff couldn't do, and I got management to go for it. Who did they pick to lead the team? Me! It was going to be my first chance to be a team lead and have a voice in everything from design to tools to personnel. I was thrilled. So my recommendation would be to check to the motivations of the people pushing this project.
Now that I'm older and faced with the same question again, I just decided to go with FogBugz. It does 99% of what we need and the costs are basically 0. Plus, Joel will send you personal emails making you feel special. And in the end, isn't that the problem, your developers think this will make them special?
Every software developer wants to build their own bug tracking system. It's because we can obviously improve on what's already out there since we are domain experts.
It's almost certainly not worth the cost (in terms of developer hours). Just buy JIRA.
If you need extra reports for your bug tracking system, you can add these, even if you have to do it by accessing the underlying database directly.
The quesion is what is your company paying you to do? Is it to write software that only you will use? Obviously not. So the only way you can justify the time and expense to build a bug tracking system is if it costs less than the costs associated with using even a free bug tracking system.
There well may be cases where this makes sense. Do you need to integrate with an existing system? (Time tracking, estimation, requirements, QA, automated testing)? Do you have some unique requirements in your organization related to say SOX Compliance that requires specific data elements that would be difficult to capture?
Are you in an extremely beauracratic environment that leads to significant "down-time" between projects?
If the answer is yes to these types of questions - then by all means the "buy" vs build arguement would say build.
If "Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way", the best and cheapest way to do that is to talk to the developers of existing bug tracking systems. Pay them to put that feature in their application, make it available to the world. Instead of reinventing the wheel, just pay the wheel manufacturers to put in spokes shaped like springs.
Otherwise, if trying to showcase a framework, its all good. Just make sure to put in the relevant disclaimers.
To the people who believe bug tracking system are not difficult to build, follow the waterfall SDLC strictly. Get all the requirements down up front. That will surely help them understand the complexity. These are typically the same people who say that a search engine isn't that difficult to build. Just a text box, a "search" button and a "i'm feeling lucky" button, and the "i'm feeling lucky" button can be done in phase 2.
Use some open source software as is.
For sure there are bugs, and you will need what is not yet there or is pending a bug fix. It happens all of the time. :)
If you extend/customize an open source version then you must maintain it. Now the application that is suppose to help you with testing money making applications will become a burden to support.
I think the reason people write their own bug tracking systems (in my experience) are,
They don't want to pay for a system they see as being relatively easy to build.
Programmer ego
General dissatisfaction with the experience and solution delivered by existing systems.
They sell it as a product :)
To me, the biggest reason why most bug trackers failed was that they did not deliver an optimum user experience and it can be very painful working with a system that you use a LOT, when it is not optimised for usability.
I think the other reason is the same as why almost every one of us (programmers) have built their own custom CMS or CMS framework at sometime (guilty as charged). Just because you can!
I agree with all the reasons NOT to. We tried for some time to use what's out there, and wound up writing our own anyway. Why? Mainly because most of them are too cumbersome to engage anyone but the technical people. We even tried basecamp (which, of course, isn't designed for this and failed in that regard).
We also came up with some unique functionality that worked great with our clients: a "report a bug" button that we scripted into code with one line of javascript. It allows our clients to open a small window, jot info in quickly and submit to the database.
But, it certainly took many hours to code; became a BIG pet project; lots of weekend time.
If you want to check it out: http://www.archerfishonline.com
Would love some feedback.
We've done this... a few times. The only reason we built our own is because it was five years ago and there weren't very many good alternatives. but now there are tons of alternatives. The main thing we learned in building our own tool is that you will spend a lot of time working on it. And that is time you could be billing for your time. It makes a lot more sense, as a small business, to pay the monthly fee which you can easily recoup with one or two billable hours, than to spend all that time rolling your own. Sure, you'll have to make some concessions, but you'll be far better off in the long run.
As for us, we decided to make our application available for other developers. Check it out at http://www.myintervals.com
Because Trac exists.
And because you'll have to train new staff on your bespoke software when they'll likely have experience in other systems which you can build on rather than throw away.
Because it's not billable time or even very useful unless you are going to sell it.
There are perfectly good bug tracking systems available, for example, FogBugz.
I worked in a startup for several years where we started with GNATS, an open source tool, and essentially built our own elaborate bug tracking system on top of it. The argument was that we would avoid spending a lot of money on a commercial system, and we would get a bug tracking system exactly fitted to our needs.
Of course, it turned out to be much harder than expected and was a big distraction for the developers - who also had to maintain the bug tracking system in addition to our code. This was one of the contributing factors to the demise of our company.
Don't write your own software just so you can "eat your own dog food". You're just creating more work, when you could probably purchase software that does the same thing (and better) for less time and money spent.
Tell them, that's great, the company could do with saving some money for a while and will be happy to contribute the development tools whilst you work on this unpaid sabbatical. Anyone who wishes to take their annual leave instead to work on the project is free to do so.