Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
When planning and prioritizing what is to be included in a release, do you distinguish between bugs, feature enhancements and new features?
For example, do bugs always take priority - do you fix all known bugs before working on new features? Do you use a formal system for comparing the cost vs. value of each change in your backlog? And if so, do you compare bugs and features using the same formula? Is this different for commercial software vs. open source vs. in-house corporate software?
EDIT: Some great responses - thanks. While I had a preconceived opinion that you need to treat bugs, features, enhancements all the same, and simply select the work based on the cost/benfit of each, I think the reality is that this depends on your situation.
This choice is called triage, a term from emergency departments in hospitals where they have to decide who gets treated (and sometimes, unfortunately, who lives and dies).
As with all business decisions, it's a cost/benefit problem. What is the benefit of fixing a bug or adding a feature? What will it cost (including the opportunity cost of not doing something else)?
Pick those that have the most benefit for least cost. What you're aiming for is the maximum bang-per-buck. Resources are limited, desires are not, the perennial problem of capitalism :-)
There's no point fixing a bug experienced by only one customer who's never going to throw more repeat business your way if it means a feature that will sell hundreds of copies is dropped in the meantime.
For what it's worth, our company has a database of requested changes where customers can basically vote for what they want to see in upcoming versions of our products. The actual creation of these requested changes in that database is limited to the sales force since we don't want all sorts of requests showing up without being evaluated and discussed at least a little bit with the customers.
In addition, we regularly approach our biggest customers (in terms of revenue generated) with the list to figure out what features should be added (they are free to suggest their own desires as well, which also get entered into the database - obviously voting power depends a bit on revenue).
This is quite separate from our bug system although quite often bugs are raised which are actually new feature requests, and they're shipped across to the new features database. It's possible that this may even happen for real bugs that are considered low-impact or have a suitable workarounds in place.
We ask our users.
We have a niche product, and a small user base.
Seriously, the users group are paying maintenance, or thinking about buying.
So we ask them what they would like.
They suggest fixes, ask for new features.
We tell them about the development roadmap: because we have things we want to do to the product ,
due to times changing, design ideas. Changes to regulations.
And if every customer says "we really need feature X" : then it'll come next.
If they say "you guys need to fix the bug where I click there an it doesn't do blah:" then that bug gets fixed.
Commercial software: with the customers voting for changes.
Of course, we take their choices on advisement: the company have other things that are thinking about.
We always look at the cost of fixing the bug versus the problems caused by it. Sometimes, it just isn't worth it to have every single bug properly triaged, root caused, then fixed.
Plenty of times a particular enhancement or new feature is being funded or at least strongly recommended to occur by a large/good customer, so that also affects matters.
I like to think that bug fixes should always come before enhancements and new features, in all cases. Even if the particular bug isn't bothering you too much as the developer, someone somewhere is having their day ruined when your little error pops up.
distinguish, yes.
bugs take priority, yes.
all critical / normal priority and above bugs first, yes.
yes, the 80/20 rule.
no, bugs and features have to be treated differently because they are weighted differently.
yes, all commercial, open-source, and in house applications have their own way to do things.
As an example, FogBugz uses Evidence Based Scheduling and is the only management/tracker that i know of that uses that formula.
Hope that helps!
You have to look at it from the standpoint of what the bug is. A show-stopper bug is always number one priority. If people can't log in or critical data can't be entered or adjusted, etc. then that must take precedence over pretty much everything.
Bugs of lower significance can be worked in as need be. We may delay fixing a bug becasue we know we are working on that section for an enhancement next week. Then the bug fix will go with the enhancement. We may delay fixing a bug if it is minor and a planned enhancement will replace the code entirely shortly. A major enhancement might take precendence over fixing some typos on the interface. A client may tell us that this other project is more critical and to do it before fixing the bug (our software is highly customized by client). It all depends on the affect of the bug and existing plans and corporate politics once you are past the show stopper. A bug that is bothering a major client may take higher precedence even if it seems minor to the developer. If the CEO wants it fixed now, doesn't matter how unimportant it seems compared to the rest of the workload, it gets fixed now.
Point 5 of The Joel Test: 12 Steps to Better Code makes a compelling argument (in my opinion) that it's a good idea to fix bugs before writing new code.
For bugs, it's pretty simple: If you're going to fix it, fix it before you write any more code. Why? The more code you add, the harder the existing bug will become to find.
If you're okay with the idea of the bug never being fixed, by all means triage it over and add features.
Bugs? We have no bugs. They're undocumented features.
For us the choice is always based on business decisions and as a developer I have no input beyond offering my opinion on what should be top priority. More often than not, features win over bugs because adding features "appears" to the business area like progress is being made and bugs that I could have fixed a year ago continue to exist because the business side only wants to see "progress". Triage is great if your allowed, but all too often in the corporate environment, it's about visible results, not functionality.
One thing did not mention so far the severity of the bug. If the bug has high severity (like crash , can not pass duration test, and it surely depends on what kind of application you have) ,you should definitly fix it first before adding new feature.
The company I work for is trying to implement a release schedule and I want to get some constructive feedback from people that work in better structured environments than I am in.
We have one product that is finished and being used by several customers, but we have 4 additional products in the works - and actively being marketed as if they are finished. (Imagine that!)
We are a very small company working very quickly (and yes, sloppy at times) and with tight deadlines and tight budgets, so we don't have the luxury of written requirements, systematic QA process, etc. Basically the owners of the company come to the developers (3 of us) with ideas and we implement them. Then the subject matter experts test the features to make sure the app does what it is supposed to do.
I know that last paragraph opens me up to all kinds of "you can't do it this way" types of feedback, but I don't need that. I understand how wrong this approach is. At one point I was able to convice the owners to hire a project manager and a QA person, but after a short time both were laid off due to loss of revenue. We are where we are and there's no changing the culture at this point.
What I'm trying to do is manage expectations. We have a list of requested features a mile long and here's what I have proposed.
We will do quarterly releases to production of our finished products. The first release will be in October. Rather than trying to manage what will be done between now and then based on High/Medium/Low priorities, we will manage features based on what can and cannot be finished between now and September. At that point we will stop all feature development and focus on testing and fixing defects in order to get the product ready for release the following month. We'll repeat this process each quarter. Basically the steps will be like this:
1) Place all outstanding features into a future release based on how critical it is.
2) Work on these features during the quarter.
3) As new features are requested, place them into a "queue" for a particular release cycle.
4) If the feature has to go into the current release, then move other features to the next release.
5) At certain points during the cycle, evaluate which features may not get into the current release and adjust accordingly.
6) End development of features at least 30 days before scheduled push to production and focus on testing and bug fixing.
7) Push something to production on the scheduled date and then take the heat for not having everything finished that we agreed to in the beginning (hey, I'm being realistic...the people I work for aren't.)
Oh, also, if you plan to tell me to "get a new job" then don't bother answering. That's not an option at the moment.
If you have any advice regarding this proposed approach, or any links to resources that might help me better understand how to structure this process, I would greatly appreciate it.
Thanks in advance for your help.
Darvis
Given the lack of project management, organization, etc - I think you're going to run into problems trying to force yourself into a quarterly (or any fixed date) release cycle. This will be especially true if you have any "large" features which will take more than the 2 months to develop that you're allowing for development time.
My suggestion would be to do a feature-based release cycle. Just make your queue of features, decide which ones you think you can reasonably do in a specific time frame. Implement those features, give yourself one month (or whatever) for testing, then release. Move to the next group of features. If it takes 2 months instead of 3, great. If it takes 4, that's fine too.
That being said, I'd focus on trying to make this shorter, not longer. Having more, smaller releases will actually help you in this case, especially since you don't have the formal procedures (and personnel) to handle QA, etc. Staying flexible will help you fix problems that will get into your releases...
Quite simply, given the lack of defined process, there's not much chance of successfully implementing a solid release schedule. This isn't just pessimism, although I'l readily admit that it is.
Much like success being based largely upon hard work and a little luck, solid, repeatable release schedules are based upon process; having things such as functional specifications and design specifications are really critical to being able to release on a consistent, solid schedule. (You know there's a reason why people have such specification things, right?) And that's not to say that you can't hit your schedule and release expectations without such things; you very possibly can. But what having such process in place massively increases your chances of being able to meet expectations, at least partially because it assures that expectations don't drift into "unreasonable" territory while you're still implementing.
Again, this doesn't mean you can't achieve what you need to doing what you described above; to be honest, if you're in an environment that is actively hostile to having such process as described in place, you're probably working in the best way to achieve what you need to. And I don't mean to be completely pessimistic; it sounds like you've got a good grasp on how to attempt to get this stuff done; for what you've got to work with, it sounds like you've got a reasonable process in place. But I can virtually guarantee that you'll end up being better off if you can just get two things; 1) a functional specification from management that describes what they want the software to do, and 2) a design specification from engineering describing to management how you're going to make the software do what they want in the functional specification. I'd think you could possibly even fit this into your process; functional specifications don't need to be complicated; the key thing about them is that they are written down, which prevents bickering about what management asked for; it's right there. And design specifications don't need to take a lot of time either; a quick one-pager to let management know how (at a high level) you're going to implement what they need provides them with reassurance that you've heard them, and can help them understand the complexity involved (but don't go too deep into it, otherwise you run the risk of boring them and losing their attention).
Release early and often.
I often find that users don't know what they want until we show them. In our facility, we have a light-weight QA/test system. Let users try new things. As users approve of ideas, we move them to production. This lets us always be working on new things, testing interfaces, adding database tables and columns, without breaking production code.
The only "trick" is constantly reminding the customer that the test platform is not the production platform.
What are you using for source control?
We use SVN and have the flexibility to if necessary create a variety of different branches depending on what's to be deployed as of the next release. If releases a1, a2, and a3 are set to be released, we can merge these changes into a branch off production. If a2 becomes less of a priority we can roll back only a2's changes or if there's overlap just create a new branch and merge only a1 and a3, leaving a2 for some later release.
How likely are the owners to rewrite a specification prior to a given release? Where I work this happens frequently, making the ability to shift gears and rollback / re-merge if necessary very helpful.
My company also gets bogged down with feature requests.
What we did is go through all the features and give an estimate of the amount of time they will take to implement. Then, we leave it up to our "change committee" (our CEO, team leaders, etc.) to give us the features we will be completing during the next sprint.
This way, we aren't being given unreasonably large work-loads, and the end user has some say in what's completed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In your opinion, who should fix a bug? A programmer, right? OK but really, who... let me explain.
I'm a Scrum Master across a number of Scrum projects. Scrum says 'ring-fence your resources where possible', a sentiment I whole-heartedly agree with.
Generally we integrate a certain %age of each sprint to be bug-fixing from the previous sprint(s) - all well and good.
After each Sprint we Demo and Restrospective to our clients, and promote our development code to a UAT environment (our client generally doesn't want a small bit of his project to go-live, but that's up to them - we're keeping our side of the bargain by ensuring we deploy working and testable code).
Once all sprints are complete we have a UAT phase where the client takes a thorough test of the completed software to find any last minute bugs. Now ideally these would have been caught already, but realistically there are a some that only discovered during UAT.
During this UAT phase, not all the developers are needed on the project 100% of the time, and so we like to reallocate them to other projects. However, Scrum says 'ring-fence your resources where possible'.
My problem is, I'm allocating developers to the UAT phase of one project while starting a separate Scrum project with them elsewhere. Not ideal - however, this is a commercial reality at the moment.
I can either:
1) Live with it and have developers fix their own code - and allocate some time (say, 20%) of the developer to the previous project's UAT.
2) Ensure a handover is in place and have 1 or 2 developers dedicated to bug fixing code 100% of the time.
I like 1), but it makes resourcing a real pain in the arse.
2) scares me, I feel developers won't take responsibility over the quality of their own code. I feel there's a lot to be said in ensuring developers take ownership of their own code - and asking them to fix their own bugs is a good way of ensuring quality. Noone likes fixing bugs, so I've found developers generally try and do a better job up front knowing they'll have to fix any issues that are raised anyway. However, 2) is easier to plan and resource. But 2) will take longer, as fixing a bug in someone elses code is costly in terms of time and resource. If it is a complicated fix, it may need the original developer's help anyway, and it will certainly take longer to fix by someone who isn't as familiar with that section of the code base.
What do people think?
People should fix their own code. Take advantage of the fact that no one likes going back and fixing old stuff when they could be writing new stuff. If the developer responsible for the bug can be identified, make sure they are responsible for fixing the problem. This will encourage developers to be more diligent in writing clean code the first time since no one wants to be seen as the person who has to keeping fixing things they've broken. This is true during development as well when someone breaks the current build.
Update: Having said that, I wouldn't necessarily be dogmatic about it. The customer's needs come first and if the person who created the bug can't be reassigned to do the fix, you may have to assign the fix to someone else.
ScrumMasters don't allocate developer resources. ScrumMaster is a role fulfilled by someone on the Team.
That aside, the Product Owner is the "on the Team project manager", and should be fighting to secure the resources that are needed to stablize the product into production.
Engineering practices have to be improved so that the Team(s) are approaching zero bugs. "Bugs" that live past the end of a Sprint have to go on the Product Backlog to be prioritized by the the Product Owner.
This is a very interesting topic, project management is vital and the apprpriate allocation of resources is essential.
One point I would raise is that having dedicated bug fixers may increase the quality of the code. If I was developing code that had my name against it that I knew other people were responsible for I would do everything I coudl to make sure it was good code.
Perhaps a combination approach is required.. You could take a couple of developers on any project - a different pair on each project - and make them resposible for the bug fixing phase outlining that responsibility up front. That way they can ensure they are up to speed as the project goes along as well as a handover at the end. Your resource allocation is easier and the client gets top notch support.
Just a slightly different way of looking at it.
Cheers
Nathan
Your team should NOT be starting new project work until the current one ships. I think most scrum practitioners would argue that there is no place in scrum for UAT (as it was done in waterfall). What you are looking for is called a stabilization sprint and is your last sprint right before go-live. The WHOLE team works on it. Stuff that gets done during this time includes last minute bugs, GUI beautification tweaks, roll-out documentation, help guides, operations training, and long lunches. It is also potentially a great time for the team to learn something new on their own without the "pressure" of delivering backlog items or to unwind a little before starting something new. Based on your customer's UAT timeframe expectations; if it tends to be on the longer side; you might also put off non-customer facing tasks to this sprint such as log monitoring, server setup scripting, maintenance screens, or other misc tool building.
Whatever you do, don't do any work outside of the Sprint boundaries. It is a slippery slope into waterfall-esque scheduling oblivion.
I think bugs should be fixed by the original developer. Making developers to fix bugs in code that was written by someone else could take a lot more time and moreover could make them demotivated since fixing bugs is not that very exiting.
I vote for #2. As a developer I hate context switching and that's what you essentially impose with #1. As for the code ownership issue, having developers own pieces of code is an anti-pattern. Strive for shared ownership: introduce pairing, rotation etc.
To second #kevindtimm's comment, UAT is just another sprint. Perhaps w/ less developers.
On the other hand, the core of Agile Software manifesto is to deliver business value incrementally, so ideally you're supposed to push to PROD at the end of each sprint. If so then shouldn't UAT be part of every single sprint. Isn't that what the Demo is for?
I really don't like option 2) because:
It gives people the feeling that the job has been done while it hasn't (it's not DONE, there are bugs),
I think people should be responsible for the code they wrote, not others,
I don't think that "bug fixer" is a job, you are not respecting people when doing this.
So option 1) has my preference (but please stop talking about resources and resourcing).
Finally, a little quote:
If you have separate test and fix cycles, you're testing too late. --M. Poppendieck
Yes, I know, it's easier to say than to do... but nevertheless, she's damn right.
I am a lead developer in a Scrum driven team. The way that we tend to work it in my organisation is this:
Before the starts of a sprint each developer will be allocated a percentage of how productive we think they are going to be during the sprint. For example a more skilled more experienced developer will probably be able to be productive 70-80% of his total time during the sprint. This gives time for unexpected meetings, bug fixes. I will come onto the bug fixes in a moment. We will get the estimates for all the tasks signed off and then plan the developers work.
Going into the sprint the developer will carry out his planned work and complete his own testing. If Possible as each block of work is completed another testing phase will take place either by the Scrum leader or the product owner (project manager) just to make sure that there isn’t anything glaringly obvious that needs to be looked at. Anything that comes up in this testing phase goes straight back to the developer that wrote it to complete in the sprint. The way we see it is that the team has effectively committed to completing the tasks given to us at the beginning of a sprint so we needs to complete them one way or another.
If an urgent bug comes into the team and it has to be done right this minute then myself and the scrum leader will take a view on whether or not it it is possible to get it done without effecting the planned work depending on how well we are doing. I.E. if we are half a day ahead of schedule and the estimate on the bug is half a day we will do it without changing the planned work. If that’s not possible we go back to the product owner who decides what it is that has to be pulled out of the sprint.
If a non urgent bug is assigned to the team part way through a sprint then the product owner give it a priority and it will remain in our pot. When the product owner then comes up with our next set of objectives he will prioritise the bugs and the project work together and these will become our planned items for the next sprint.
The thing to note is that it doesn’t matter which project the bug came from. Everything has a priority and that is what needs to be managed. After all you only have a certain development resource. When it comes to which developer does it that depends on several things. you don't always know exactly whose code introduced the bug. Especially if it’s from a very old project. If the same developer can fix it then there is obviously a time benefit there but that exact developer might not be available. The way that we try and work it is that any developer should be able to work on any given task. In the real world this isn't always possible but that that is always our end goal.
I realise that I have been beating around the bush here but in answer to your question about who should do the bug fix in short this is what I would say:
If the bug is identified during the same sprint that the work was being done then send it back to the original developer.
If its urgent then it has to go to the best person to do the task because it needs to done as fast as possible. That might not be the person that originally wrote the code it might be someone with more experience.
If you have prioritised and planned the bug then you should also have time to work out who is the best man to do the job. This would be based on the other work that needed doing, the availability of developers and your general judgment.
With regards to handovers these should be fairly minimal. At the end of the day your developers should be writing code in a way which makes it clear, clean and obvious to any developer that has a task to revisit it. It is part of my job to make sure the developers on the team are doing this basically.
I hope that this helps :)
Part of this falls onto the Product Owner to prioritize if some bugs are more important than some cards to my mind. If the PO is, "Fix these bugs NOW," then there should be bug fixes moved up to the top of the list. If there are numerous high priority bugs then it may be worth having a stabilization sprint where bugs are fixed and no new functionality gets done. I'd be tempted to ask the PO how much time they want spent on bugs though I'm not sure how practical that is.
The idea of having maintenance developers is nice but have you considered where there may be some pain in having to merge code changes from what maintenance does and what those developing new functionality do? Yeah, this is merely stepping on toes but I have had some painful merges where a day was spent with 2 developers trying to promote code due to so many changes between a test and dev environment.
May I suggest the idea of another developer fixing the bug so that someone else picks up how something was coded? Having multiple people work on some feature can help promote collective ownership rather than individual ownership of the code. Another part is that sometimes someone else may have an easier time with a bug because they have fixed that kind of bug before though this can also lead to a dependency that should be checked regularly.
Why not capture a backlog item called "bug debt", and have the team estimate it each iteration. That item will be used to hold some developer's time to fix it (as in #1).
I'm also a little concerned about the bugs that appear in UAT. Would it be possible to have some of those testing folks on the teams to catch them earlier? This kind of thing is very common in projects where it's thrown over the fence from group to group. The only way I have seen that works is to integrate those other groups into the teams and rethink the testing strategies. Then, UAT does what you want it to do... capture usability issues and requirements. You're right they won't go away completely, but they will be minimized.
I think people should fix their own code as well. Why waste all the time with handovers?
It might be worth doing UATs as and when each feature is complete; so the "testers" working along side the "developers" testing functionality as they go. The testers should be able to run through the UAT criteria.
If there are more issues within the UAT with the stake holders, then they are change requests or the acceptance criteria is probably ambiguous in the first place!
I've generally followed option 1. Often because resources go to other projects. If you do root cause analysis by discussing how bugs were created, there's a small side effect of public embarrassment. If you've instilled any sense of ownership on a project, your developers should be more than a bit embarrassed if their code is displaying a higher percentage of bugs than others or what is reasonable.
I typically find that in these cases, most developers are actually frustrated if their too busy to fix their old bugs. They don't like it when somebody else has to clean up their mistakes.
Instilling a sense of ownership and pride are critical. If you haven't done that, you are always counting on the threat of punishment to get them to do the right things.
Always try to have the original developer fix their own bugs, IMHO. This part is easy. If you've got a few developers who behave unprofessionally and shirk their duty to produce high quality software, give them the boot. If the problem is cultural, read "Fearless Change" by Linda Rising and get to work in your SM role as change agent. I'm right there with you, so this isn't me just beating you over the head; I'm doing the same thing at my job :).
However, you've got bigger problems.
You're a Scrum Master allocating resources? Yikes. The Scrum guide calls the SM to
...[serve] the Development Team in several ways, including:
Coaching the Development Team in self-organization...
I understand we all don't have the ideal organization within which to practice Scrum; however, this should gnaw at you daily until it is improved. The Scrum gude puts it simply:
Development Teams are structured and empowered by the organization to
organize and manage their own work.
**Second, stop saying resources. Just stop it. Resources are coal, wood, and natural gas. People are not resources.**
Third, this UAT is a big impediment to the Scrum team. If I'm understanding you correctly, the client has a giant, red button they can press and completely blow up "Done" work by saying, "You've got to fix this before it's finished." Any Scrum Teams subjected to this no longer have velocity, forecasts etc. These things all measure "Done" and potentially "Done" work; they depend on "Done" software that is potentially shippable. Heres how the Scrum guide describes the Product Increment:
The Increment is the sum of all the Product Backlog items completed
during a Sprint and the value of the increments of all previous
Sprints. At the end of a Sprint, the new Increment must be “Done,”
which means it must be in useable condition and meet the Scrum Team’s
definition of “Done.” It must be in useable condition regardless of
whether the Product Owner decides to actually release it.
You can improve this UAT situation in several ways:
Convert the client's UAT to a simple feedback loop i.e. feature requests come out of the UAT, not notifications of incomplete software.
Get their UAT testers to work alongside the Developers during the Sprint and make sure the work is "Done."
Do not take work into a Sprint unless a UAT person is available to validate the work is fit for purpose.
I realize none of these will seem "commercially" plausable, but you're the SM. If no one else in the whole organization is saying these things, you have always got to be willing to.
I realize this sounds like a kick in the pants, but you need to year it from someone. This is a bit like the old shoe / glass bottle scenario from (wow) 10 years ago now.
Please feel free to reach out to me if you want to explore this further. I'm a fellow Scrum Master, and would be happy to help you work through this tough scenario.
I work on an application that has a both a GUI (graphical) and API (scripting) interface. Our product has a very large installed base. Many customers have invested a lot of time and effort into writing scripts that use our product.
In all of our designs and implementation, we (understandably) have a very strict requirement to maintain 100% backwards compatibility. A script which ran before must continue to run in exactly the same way, without any modification, when we introduce a new software version.
Unfortunately, this requirement sometimes ties our hands behind our back, as it really restricts our ability to innovate and come up with new and better ways of doing things.
For example, we might come up with a better (and more usable) way of achieving a task which is already possible. It would be desirable to make this better way the default way, but we can't do this as it may have backwards compatibility implications. So we are stuck with leaving the new (better) way as a mode, that the user must "turn on" before it becomes available to them. Unless they read the documentation or online help (which many customers don't do), this new functionality will remain hidden forever.
I know that Windows Vista annoyed a lot of people when it first came out, because of all the software and peripherals which didn't work on it, even when they worked on XP. It received a pretty bad reception because of this. But you can see that Microsoft have also succeeded in making some great innovations in Vista, at the expense of backwards compatibility for a lot of users. They took a risk. Did it pay off? Did they make the right decision? I guess only time will tell.
Do you find yourself balancing the conflicting needs of innovation and backwards compatibility? How do you handle the juggling act?
As far is my programming experience is concerned, if I'm going to fundamentally change something that will prevent past incoming data to be used correctly, I need to create an abstraction layer for the old data where it can be converted for use in the new format.
Basically I set the "improved" way as default and make sure through a converter it can read data of the old format, but save or store data as the new format.
I think the big thing here is test, test, test. Backwards compatibility shouldn't hinder forward progress.
Split development into two branches, one that maintains backwards compatibility and one for a new major release, where you make it clear that backwards compatibility is being broken.
The critical question that you need to ask is wether the customers want/need this "improvement" even if you perceive it as one your customers might not. Once a certain way of doing things has been established changing the workflow is a very "expensive" operation. Depending on the computer savyness of your users it might take some a long time to adjust to the change in the UI.
If you are dealing with clients innovation for innovation's sake is not always a good thing as fun as it might be for you to develop these improvements.
You could alawys look for innovative ways to maintain backwards compatibilty.
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.