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 10 years ago.
I've often read that corporations will save millions once Internet Explorer 6 is finally laid to rest, but reading quotes like that make me wonder just how much time people are spending on IE6 development. I'll be happy once IE6 goes, but I've found that if I write valid HTML and CSS, use a JavaScript framework, keep the transparent images issue in mind, and don't try to over-complicate my design, I only need to write a few lines of IE6-specific CSS, which usually takes about 10-15 minutes. So I'm curious, how much time, effort, and money do you or your corporation spend on preparing your sites for IE6? Also, at what point will you drop IE6 support? If you've already dropped support, what has been your experience in terms of saved time and money and what has the switch done to your conversion rates and customer satisfaction?
According to some - browser - statistics, IE6 market share is still bigger than Chrome, Safari and Opera together, nearly as much as IE7.
Unless you target a very specific market (indeed check your stats to know for sure), neglecting to make your site looking at least decent with IE6 seems a bit foolish today...
I won't take the road to tell visitors what browser to use, for sure!
I'm already phasing it out. Every second spent on debugging for an outdated (7+ years old!!) browser is a second wasted in my books. What I've started doing is when an IE6 user first comes to the site (determined by cookies and some dodgy browser sniffing), I pop up an alert informing them that they are using an old browser which does not support much of the functionality required by many of today's web sites. I inform them that their experience might be slightly downgraded by continuing, but that can be easily alleviated by upgrading to a modern web browser (even if it sucks).
Don't go out of your way to make it crappy for them (though they might deserve it), but don't go out of your way (with non-standard CSS hacks etc) for these users either. There's only one way they'll learn.
I don't like it but I still support it. For small sites it isn't a problem, just make stuff work in Firefox first, then IE7, and IE6 last. I've used IE6-only css a number of times, and those only had a few rules in them.
For a larger project with complex layouts, I have wasted a lot of time on IE6. I'd be very happy to drop it entirely if it was impossible to provide one of my major features on it. So far, it's close enough that I'm still supporting it.
According to what I read online, about 1/4 people still use it, so it's probably not wise to drop support.
http://www.w3schools.com/browsers/browsers_stats.asp
Use your own judgement, based on your application and what you think you can expect from your users. I do not believe that a typical web user will upgrade/switch their browser just for one site. I think those people who have not upgraded from IE6 by now will never be motivated to do so. The number of IE6 users is dropping, but I think we'll be waiting for them to replace their computers rather than upgrade their browsers.
At my job all of our projects are for large corporations that aren't willing to drop support for a browser with such a large market share. Also, the designs we have are dictated to us by a third party design company so, even conforming to standards, there are still issues with complex designs in IE 6.
I would say for any given page about 5%-50% of the CSS development time is devoted to IE 6, depending on who the developer is and how complex the design is. The more experienced the developer and the simpler the design the better your odds are at hitting that 5% mark :) But even myself, with a good amount of IE 6 web-dev experience, have spent 3 hours on CSS for a page only to spend another 3 hours ironing out small quirks in IE 6.
Another thing that comes up is that certain markup + CSS approaches that seem so intuitive and simple in more modern browsers don't work at all in IE 6. If you go down one of these paths, you generally have to start from scratch once you realize that your code that works beautifully in FF and IE 7 doesn't have a chance in IE 6. More lost time...
I agree with the rest of you that if you can control your project and don't care about the IE 6 market, by all means forget about it. Unfortunately, some of us don't have that luxury quite yet.
We've already dropped it, but it depends on who you're marketing to. Only other companies will ever see our product, so we can be fairly certain they're at least using an operating system that can support IE7. If you're marketing to the entire internet then you may want to make certain that nothing breaks for a while yet.
Depends on the project. If I write the code conforming to web standards usually I don't have many issues.
If I'm using a template downloaded from the web, it often spells out very clear in bold letters: "manifest destiny is a bitch. don't trade blankets with anyone."
Unfortunately, I have a bunch of friends in other businesses that are sticking with IE6, and don't have a plan to upgrade.
They don't like the tabs in IE7, they don't want to go with another browser, etc, etc, etc.
There is enough of this that filters back to me, that I continue to test against IE6, and will do so for the indefinite future. Doesn't make me happy...just do it.
The vast majority of our internal corporate users are still on IE6. Until the powers-that-be decide to push out an update with IE7 or IE8 we will continue to support IE6 as our primary browser.
As far as I know, there are no immediate plans to upgrade.
Zero. Dead and gone as far as I'm concerned.
Really, you should be answering this question for yourself.
If you don't have a decent web log statistics package such as AWStats, then there's the first thing you need to do.
Otherwise, decide how much time you spend supporting IE6, and see what percentage of your users that is. If the time-to-customers ratio doesn't balance out, then you can decide to ditch IE6. Another factor to consider is how important your product is to your customers. If you're working on Salesforce.com, you can probably assume that they'll be willing to upgrade if you prompt them to do it. If you're talking about a server that injects ads into webpages, then you'll probably be at their mercy of browser choice.
Related
Does one of you know where to find statistics on websites using web standards?
I've read multiple books on web standards, all give very unspecific data on how many sites comply to web standards.
Books like "designing with web standards", "CSS Mastery", "HTML and web standards solutions" all contain definitions like "some", "more and more" and "not nearly enough" without a source for this data.
Of course I realise there won't be an exact number, an indication would be great. I feel like those writers will need to have gotten their data from somewhere.
I would be great if any of you could point me in the right direction.
There's a very good reason that those books you read only provided indeterminate quantities like "some", "more", and "not nearly enough". It's because this type of data is not easily obtainable, not by the authors nor by us on Stack Overflow. Anything you might find would be idle speculation at best, and more likely tainted by some strong personal biases.
Those writers did get their data from somewhere, but I can't provide any more detail because this is a family-friendly site. Scott Adams used a similar theme to great success in one of his famous comics:
Fortunately, even if you were able to find this data, it wouldn't be particularly relevant. The decision to comply or not to comply with web standards should not be made based on what everyone else is doing.
As has been mentioned, there won't be any such list available. However, I believe most web developers / designers would have a good 'feel' for how many sites they've looked at conform to all standards - and my hunch would be this number would be pretty low (based on my personal experience).
If you are really keen on figures, maybe take the top 100 websites on the web and go validate them all. Shouldn't take too long and you'd get a feel for how many conform to at least basic valid (X)HTML standards.
Since all the browsers don't actually follow the standards in the same way, this leads to websites being forced to use non-standard code to ensure a consistent feature set and look and feel. The situation has improved massively in recent years but is still far from ideal.
You also have the problem that even agreeing on what the standards are can take a very long time let alone waiting for everyone to comply. The current pace of development of modern browsers means standards will always be playing catch up somewhat.
Sites such as validator.w3.org, quirksmode.org, acid3.acidtests.org, html5test.com are great to keep up with the latest cross browser techniques and browser support but attempting to code a website and strictly remain inside a set of out dated rigid standards appears a zero sum game.
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 12 years ago.
I have been using gvim at work for a year or so, just at the point where I'm loving it, getting the hang of it and trying to j,k all over Microsoft Outlook. Then my computer died. Now, originally I had installed gvim myself, which at the time was a "no-no" and is now is really a bad idea (what with all the people introducing viruses to the network and whatnot).
We have a software review board to which I was sent when I wanted gvim "legally" installed. I was told that the standard text editor is UltraEdit and they don't want to support more than one. If I want to use gvim I need to talk management into making it the standard.
I'm kind of at a loss. Obviously, I can tout the cost savings, but I was having a hard time explaining what my fuss was about. If it were another programmer, I'd just force them to use it and they'd figure it out for themselves. But management folk aren't much interested in not being able to figure out you need to "i" before you can type, er, insert.
I told my manager it was like having a rowboat instead of swimming everywhere. And sometimes you're motorboating in that thing, but I'm looking for concise, compelling arguments which aren't based on bad analogies. There are a number of similar-ish questions, but I fear they trend too technical. Any ideas?
And after all your awesome advice wins the day for me, how do I ease former UltraEdit users into becoming gvimmers?
Update:
Thanks for the answers! I accepted one but took from many (don't know if that matters as question is now closed). Even though it was apparently too open-ended it is helping me plead my case with the powers-that-be.
Seems simple enough. Tell them that you are far more proficient with Vim and that you know next to nothing about UltraEdit. Whether this is true is irrelevant - provisioning requests for software aren't delivered under oath :-)
This has two effects:
you won't need the IT staff to support you since you such a guru.
you won't need weeks of ramp-up time trying to figure out how UltraEdit works.
Managers understand cost/benefit analyses. The cost of letting you use Vim is zero. The cost of making you use UltraEdit is considerably more.
Likewise Vim's benefits are high since you're immediately productive.
The company where I work actually has two classes of software that they let us use. The first is the stuff they support. The second is stuff that you need to get yourself (off the company distribution site, not from outside, they're still paranoid about malware and rightly so) and, if you have trouble with it, don't call them.
But don't make the mistake of trying to evangelise Vim. You want to be given a choice, not try to convince everyone else to have their choice taken away.
gvim is a portable app. So don't install it but have it anyway.
The argument I would use is that individual developers are more productive in different environments and this one doesn't even cost them anything. And, on that note, while I'm a gvim lover myself, I think forcing others onto it is guaranteed to only make them hate it.
To be honest, I don't know what UltraEdit provides that Notepad++ doesn't - which suggests a waste of money.
But, their response seems like a canned "we don't want to do our job so go away". If I were in your position I would present the use cases that I used with vi and DEMAND that they show me how to do the same thing in UltraEdit because they "support" that product. And trust me, I would make sure I make multiple tickets in the ticketing system just to piss them off. And at any point if they say "I don't know", contact their supervisor and ask them why you can't have gvim installed when the techs don't even know about the "supported" software.
If they refuse to help you or take their time, contact their supervisor and tell them they are impairing your ability to do your job.
Eventually someone will listen to you and cave :).
gvim is indeed a thing of great power. Grown men have been known to weep at the mere thought of its beauty. The productivity increases provided by this tool are immense if you know them by heart, and switching back to a conventional editor can make you feel as if you are typing with only your thumbs.
Given this, I would suggest you take some sort of productivity measurement, if you can. For similar straightforward development tasks, measure the lines of code you output in n hours with gvim, and then with UltraEdit. Include tasks such as refactoring into these measurements. Then, take these numbers to management and say, "Would you have me perform at 1/x the speed that I could be performing? Remember, this is dollars and cents we are talking about!"
Also assure these naive creatures that gvim is not a virus and will not take down the network in flames. It is, in fact, a text editor.
Implore them to amend the standards to allow for the application of a little logic. A little logic can go a long, long way.
Good luck to you, roger. As a fellow gvim enthusiast, I salute you.
This question is a better fit for programmers.stackexchange.com. But anyway. I think this whole "everybody at work must use one editor only" is absurd. Whatever happened to "different strokes for different folks", especially for creative types like programmers?
If your work doesn't see programmers as creative types, then you have a bigger problem. Time to visit careers.stackoverflow.com. ;-)
As a personal aside, I type with Dvorak. I don't necessarily want to convert all my workmates to Dvorak, but, I would find a different job if work made me use qwerty. There is simply no way I would agree to retrain myself on qwerty given that I type at 100 to 120 wpm on Dvorak, and no amount of qwerty training will get me to that speed.
Under these circumstances, I would consider going rogue.
I'm afraid you've presented a no win situation that I've faced many times in my programming career - a draconian policy inflicted on productive employees by middle management. A vain effort to homogenize the environment and work force beyond any level that can be considered reasonable.
Ponder the consequences of going rogue, by installing vim on your box anyways, and see if they are worth the benefit to you. If you decide that it is worth it, just do it. It's not like you are doing something illegal, after all. If the consequences are dire, I'm afraid you will have to cave in and start using UltraEdit. It's not the end of the world (it could have been notepad), but as an avid vim user myself, I feel your pain.
Update: I see people are voting me down, but this is the real world and the real world isn't perfect(ly theoretical in nature). Sometimes sacrifices have to be made, but in the end it's still your decision and only you have enough information to weigh the consequences. All we can do is present you with options, some more extreme than others...
Programmers are a very expensive resource, and you are losing productivity by using UltraEdit. Just do a little math:
Suppose you spend 60 minutes a day for a month dealing with UltraEdit instead of programming. Then, maybe after month of adjustment, it only takes you an extra 30 minutes a day to use UltraEdit. Add those minutes together, and you get nearly 20 days per year! This means it costs your company nearly a month of your time every year to use UltraEdit.
Now find a few colleagues who have similar opinions. If four or five of you get together, the amount of lost time gets really big really fast.
Just flip the numbers around, and tell your manager that you know a great way to A) save the company a bunch of money or B) greatly improve programmer productivity.
Whether that argument will work depends on your company (and your position in the company).
The people who craft IT policies should understand that a programmer's computer needs are quite different from those of the average business user.
I've met a new friend. That's a woman and she is a designer. And she has a strange attitude towards IE of version 6 (and older). She just LOVES it. And she has a strong argument: "when I started programming websites, there were no "correct" browsers", so she beleives, that IE is the most correct ever. I'm a programmer and I was always scared by designing something, but I am not new to CSS, HTML and Javascript. However, professionally, I just lack serious proofs, that IE actually never tried to follow any standards.
And now I have problems trying to prove my position. From a lot of professional literature I read in my life I heard, that IE really violated standards seriously both in HTML, CSS and JavaScript. But I can't find valuable of this fact. Can you help in this quest? :)
With all due respect, you're both probably wrong.
First off, it's probably not subjective or controversial to say that IE6 is horrible.
But, at the time it was released almost ten years ago, AFAIK IE6 was one of the most standards-compliant browsers out there, in terms of CSS compliance. The problem is that the standard evolved significantly since those draft revisions ten years ago, and there hasn't been the push to auto-update the browser like Firefox and Chrome have. That has left a significant installed base of IE6 around.
She probably loves the browser because she's let her skills lapse in terms of CSS.
Saying "it was good when i started" is not a strong argument. She reminds me of a point that Crockford made in his talks, that the main opponents to technology, the ones that were the most prone to oppose change was us, the power users... "I never use this feature, but still get things done therefore this feature is crap" is a common bias, even when you know about it and look out for it...
IE6 was the very best at a time. Not anymore. Things change... As pointed, the ACID test, the user experience and most of all the non-implementation of all the standards that could help us advance are all valid reasons for axing IE6
But anyway, is it important that your lady friend likes IE6? Do you feel strongly about it? Perhaps you should let her like what she wants and not think too much about it :)
Well, ACID is a test page testing browsers if they follow certain web standards.
For further reading have a look at http://en.wikipedia.org/wiki/Acid2 .
Internet Explorer has and will ever ( ;-) ) display web pages differently from other browsers.
Suggest her to try CSS Zen Garden's "Gemination" both on IE6 and Firefox.
Run the acid test, it is the best proof. Here you have a whole browser comparison test: http://www.pcgameshardware.com/aid,687738/Big-browser-comparison-test-Internet-Explorer-vs-Firefox-Opera-Safari-and-Chrome-Update-Firefox-35-Final/Practice/
The problem is that IE6 is still the standard browser for a lot of users. If a design is created on IE6 without pushing the limits much, then it is lickly to look OK on all broswers.
So as a tool for a web designer, IE6 may be the best browser. (Just don't ask me to use it on my personal PC!)
As part of a wide ranging job for a cystic fibrosis support organization, they'd also like a web site set up and I've decided on Apache running on Linux (due to its security and low cost mostly). Other than (fairly) static content, they also want a forum where people can discuss issues with the condition - it'll be attached to a hospital chain so there'll be plenty of medical staff there who know little about the web.
I can handle all the specific coding and Apache setup since I've done it before but I'm interested in people's opinions as to whether I should roll my own forum software or get a hold of some ready-built stuff. I've not had any experience with forum software but I could generate my own (initially buggy, I'm sure) in a month or so.
It'll require registration and login to leave comments (but guest access just to read) and I'd like it to be 'pretty' (excuse me while I remember damning customers for providing similarly vague requirements specs :-) but not necessarily infinitely-configurable with skins/themes/etc.
If anyone has some compelling reasons (and experience with specific products that can provide what I need), I'd be interested in hearing about them. Alternatively, does anyone have any 'gotchas' they experienced while coding their own forum software?
Advantages to rolling your own:
a non-standard custom-built system means you'll be less prone to "standard" attacks (e.g.: a vulnerability in PunBB) since bad guys tend to bother with exploit-hunting only on widely-deployed systems (more return on their investment)
absolute control over how your system works and looks
you'll learn a lot
Disadvantages:
you'll repeat mistakes other people have already solved
it'll take you longer to get up and running
long-term it'll be more maintenance (since you have to fix bugs & add features yourself).
you can't "leverage the community" -- if you choose an off-the-shelf forum that has a plugin system then there's a whole bunch of community add-ons that won't be available for your custom forum software.
There's a GIANT list of forum software on wikipedia -- there's most likely something in there that will suit your needs that you can get up and running quickly.
IMHO the old "don't build what you can buy" adage applies to this (well, the web 2.0 version is obviously "don't build what you can download"). Have a look around at the available forum software, pick one that covers 99% of your needs and tweak it to do the rest.
If you still want to build your own forum software that'll probably be a cool side project but if the job is to get a forum up and running, then go and download one - don't try to mix up the desire to do cool stuff and the day job unless the day job is just to do cool stuff only.
One of the best-kept secrets on the internets is a little gem called FUDforum, by Ilia Alshanetsky.
And yes, it's the same Ilia who wrote xDebug's original profiler code, improved the caching in MMcache, fixed several security bugs in libmcrypt, and who was the release manager for the PHP language from 4.3.3 to 4.3.6+. He is, as my friends in Boston would say, wicked smaart.
Because of this, FUDforum is robust, ridiculously fast and more secure than probably any other part of your web application will ever be. It comes with a neat install script and it has all the features you'll need.
Plus, it's not a high-profile target like phpBB or vBulletin, which means you won't have to worry about spambots constantly banging on the gates.
Having written my own forum software before...
It seems like a simple problem, but when you get into it, you find that there's a lot of little things that you'd like to do nicer, and it takes a lot of time. Mine was cool and all, and I did get paid for it, but if I was doing it over again (which has also happened), I'd use a customizable pre-made solution, and spend all my spare time doing something productive. :)
Forum softwares tend to have rather complex minimum requirements. A few things you are very likely to need do matter what you do:
Forum/thread/post hierarchy;
User system;
Security system (eg user/admin classes and all kinds of restrictions for users);
Gathering statistics;
BBCodes or some other minimized markup language (NEVER allow users to do full HTML);
File uploads and avatars;
Bans and other punishments;
CAPTCHAs;
etc.
Ready made forum systems provide this out-of-the-box and lots more. Setup is mostly easy too. Why do it all over again yourself?
My answer would be: don't reinvent the wheel, there are plenty of fora software out there. My preference would go for RForum if you need only that.
I'd say, don't waste your time. phpBB 3 is pretty stable, usable and feature-rich forum. We use it at work (for our internal discussions), and I really don't have anything bad to say about it.
I'd concur with most of the above posters that since you want something which appears fairly standard, why reinvent something that already exists?
Like any development, creating forum software is probably much harder than it looks! There will be problems solved in the existing software which you haven't even considered.
It's worth adding that if you do require any specific additional functionality, you can always build that on top of an existing solution anyway, which is especially easy if you have the source code (whether open source or commercial).
From the sounds of the website that you are building, there is the potential for the forum to be a highly useful and visible resource, it would be good to go with something that already exists, due to the quality of a lot of the products out there and the rich communities that surround them.
I think that vBulletin, although a paid for product, would suit your needs and give you a great base to build a community on.
vanilla is pretty bare bones and easy to configure, perhaps find a system which is easy to extend vs building everything yourself
Ready built until you have some really unique features needed that can be tied to money it will make you.
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.