The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Is Bugtracking a symptom of a Heavy Process?

I read this article the other day:
http://www.bestbrains.dk/english.aspx/Articles/Why_Bugs_should_not_be_Tracked

"Using a bug tracking system reflects your expectation that you will have a lot of bugs to keep track of. However true from the beginning, this expectation often becomes self-fulfilling."

It's a rather interesting perspective, I find. I am not sure I agree but I never thought of it that way.. What do you think?
John Daniels
Tuesday, April 24, 2007
 
 
Communication has high costs.  When multiple people are working on the same project, we use tools to attempt to mitigate those costs.  Bug tracking is just one example of a communication tool.

Tuesday, April 24, 2007
 
 
Don't get a bug tracking systems until you have enough bugs to require one.

Also….Don’t by a car if you don’t have licenses, first get the licenses. This is like getting a source control app for just one developer. Just because you have a solution doesn’t mean you have a problem.
Anon Ranter
Tuesday, April 24, 2007
 
 
er, it seems to say 'you shouldn't track bugs, instead you should .. track bugs' im not really sure what the author is trying to say about priorities - im not aware of bug tracking software that doesn't allow prioritisation.
jk
Tuesday, April 24, 2007
 
 
The subject article is one of the silliest things I've ever read.

I have to assume the author is a college student or instructor. He or she can't possibliy have worked on a non-trivial software project.
Jim Howard Send private email
Tuesday, April 24, 2007
 
 
Mr. Lars is just trying to be provocative.  He's also completely insane.  What IS in the "agile" kool-aid?

After your first stab at something, if you don't have two major bugs, three areas for improvement, at least two cosmetic fixes, and a change to your build process pending, all of which need to be written down as they're discovered so they're not forgotten, and prioritized so you don't waste resources putting lipstick on a pig, then you're doing something pretty trivial.
Brent Send private email
Tuesday, April 24, 2007
 
 
Why shouldn't a single developer use a source control system?
farmboy Send private email
Tuesday, April 24, 2007
 
 
>> Why shouldn't a single developer use a source control system?

Again wrong question….

I Ask you.. Why should a single developer use a source control system?

Do things for a reason, not because there is no reason not to.
Anon Ranter
Tuesday, April 24, 2007
 
 
Seems to me that it confines rather well with the principles of lean software development (http://www.poppendieck.com/lean.htm). After all, what is the point to having loads of bugs piling up? We use Trac at my workplace and though I am happy with it, it does seem that the important issues find their way into our plan either way, and there are definitely a lot of bugs that are just rusting in there.
John Daniels
Tuesday, April 24, 2007
 
 
> Why should a single developer use a source control system?

* You can undo changes.
* You can keep track of changes over time.
* You can support multiple releases while continuing with the main line of development.
* You can recreate the state of the code to a certain problem to diagnose issues with previous releases.
Hector Quartino Send private email
Tuesday, April 24, 2007
 
 
* You can undo changes.
* You can keep track of changes over time.
* You can support multiple releases while continuing with the main line of development.
* You can recreate the state of the code to a certain problem to diagnose issues with previous releases.

Any smuck who can copy an windows directory can do this...
Anon Ranter
Tuesday, April 24, 2007
 
 
I didn't read the article, but I sympathize with Mr. Lars' point of view. As Anon pointed out, there's a tendency for management to do things for the sake of completeness rather than actual value.

I think the bug tracking application is a poor example since every developer pretty much has to make a to-do list eventually, and a bug tracker is pretty much a glorified to-do list.

A better example would be "change management" as in you need to perform an impact analysis and get approvals on every change you want to make. In fact, it tends to be an all or nothing process - either you don't apply it, or you apply the same heavy hand to both simple bug fixes and major feature changes.

The other day, a customer asked us to change a phone number in an HTML page. Unfortunately, the web application is/was a legacy application with hard coded text strings instead of a database driven template, and all of the pages were controlled in a source code repository. It took something like 5 hours of paperwork and meetings and approval to make a 30 second change.

That, is a heavy process.
TheDavid
Tuesday, April 24, 2007
 
 
Why should a single developer use a source control system? Are you serious?

- The ability to always know exactly what you shipped and to be able to recreate that version at any time in the future.

- Code in v1.1 has features unique to a single customer. If that customer needs a new feature, that feature can't be based off the current 3.2 release, you need to work on 1.1. Branching is your friend.

- If a defect is reported in v2.0, but not reproducible in 3.0 then you need to build 2.0 to find it because it's probably also in 3.0, just well hidden.

- The ability to make huge changes, realize that it's a bad idea, and then rollback to the version before those changes were made with no consequences.

There are many "solutions looking for problems." Source control is definitely NOT one of them.
farmboy Send private email
Tuesday, April 24, 2007
 
 
Any smuck who can copy an windows directory can do this... put em on a fileserver and throw the source control system away for the team, too. Who needs that bullshit?
Anon Ranter
Tuesday, April 24, 2007
 
 
Issue tracking is a measure.  It measures the application's ability to effectively deliver on its intended purpose.  The author swims around this by saying customers can contact the help desk - but these should never be used by the developer.

Issue tracking is good for these reasons:
 - An issue can be measured for affect.  A minor issue that affects everyone may be more important than a major issue that affects a small minority.
 - Issues can be prioritized.  While it is nice to think that a team can work through all issues in near real time - that is a fantasy for all but the simplest applications.
 - Resources are limited.  As a business you need to focus on the best ROI.  As a developer we can do what is fun - as business owners ROI pays the mortgage. 

** I use issue tracking to avoid the bug vs. enhancement vs. feature argument.
MSHack Send private email
Tuesday, April 24, 2007
 
 
As for source control or any processes - I agree that you should avoid doing things without a purpose.

However, if you do not understand the value of source control over a backup or even what makes something a common "best practice" the discussion is moot.
MSHack Send private email
Tuesday, April 24, 2007
 
 
Somebody is posting under my name... Just Wonderful.

Just remember we are talking about a ONE developer app. GENERALLY in this scenario the benefits of source control don’t out weight the headache. AND YES THERE IS A HEADACHE! 

I’m done posting on this topic, all further post under my name should be assumed to be from anyone but myself.
The Real Anon Ranter
Tuesday, April 24, 2007
 
 
I suppose a shmuck also can compare the instances of a same file (from Windows directories that he copied) side by side using the trusty eyes?!..
asmguru62 Send private email
Tuesday, April 24, 2007
 
 
The bug tracking system and the source code repository are straw men.

The original argument is that if you're doing things right, you obviously won't have bugs to track. By that same token, if you have a bug tracking system, you'll feel compelled to record stuff in it.

It's the "empty sofa next to the front door" syndrome. People have a tendency to put stuff on it so that they feel it's being used.

The same argument applies to source code repositories; it makes things a hell of a lot easier just like IDEs are better than Notepad, but in a pinch, you can still live without them.

What Mr. Lars is questioning is whether a big expensive robust bug tracking system is like the empty sofa by the front door; it's very presence makes developers look for ways to fill it up.

Sorry, but I wanted to nip the version control argument in the bud since it looked like it wasn't going anywhere.
TheDavid
Tuesday, April 24, 2007
 
 
Joe in Jamaica: Hey Mary, I was wondering how it was going with that problem I had yesterday?

Mary in Miami: Don't know. We keep everything up on our walls using index cards. You'll have to fly over and check.
son of parnas
Tuesday, April 24, 2007
 
 
How is the schmuck who can copy a windows directory is supposed to do diff? And even more important, merge?
Of course he can do it by hand, but it is probably not the best use of his time.
Jeff Zanooda Send private email
Tuesday, April 24, 2007
 
 
<quote>
Joe in Jamaica: Hey Mary, I was wondering how it was going with that problem I had yesterday?

Mary in Miami: Don't know. We keep everything up on our walls using index cards. You'll have to fly over and check.
</quote>

Fire Mary. She can't think for herself. It doesn't matter WHICH process you're using, she's going to do damage.

As an aside, I've personally experienced a project where we didn't need a bug tracking tool. We used one anyway, but we didn't need it.

I'm working on a project right now that looks like it could be the same.

The idea that using a bug tracking tool generates bugs (like some sort of bizarre variation on the Uncertainty Principle) is... interesting. But the idea that if organizations spent as much money of preventing defects as they did on tools to track them they might be better off, well, that might have some traction.
Bruce Rennie
Tuesday, April 24, 2007
 
 
> Fire Mary. She can't think for herself.

She can think that she would rather spend her time working than reading index cards to people. Perhaps it's you that can't think?
son of parnas
Tuesday, April 24, 2007
 
 
Perhaps it was Mary's idea to use the stupid cards in the first place?

Tuesday, April 24, 2007
 
 
> Mary's idea to use the stupid cards in the first place?

Mary is not that stupid.
son of parnas
Tuesday, April 24, 2007
 
 
If Mary was a super-star, she would requisition a web cam so the Jamaica office would have read access to the bug tracking data-wall.

Tuesday, April 24, 2007
 
 
Geez, now there's a thought.

You mean there are other options besides essentially telling a co-worker to do something anatomically uncomfortable?

Who'd a thunk it?
Bruce Rennie
Tuesday, April 24, 2007
 
 
It seems like his basic argument is that if you're developing agilely, then you should be able to fix most bugs immediately when they're discovered. Anything that you can't fix immediately goes on the list of the 25 (or so) tasks for this iteration, thereby bumping something else off the list.

I'm sure this approach works (in some sense) for simple projects with small development teams and very few users. I think the biggest flaw with it is the idea that all bugs fall into one of two categories:

1. So simple it'll take less time to fix it than to report it.
2. So important, thay must get fixed before the next release.

Anything that doesn't fit these two categories, would by definition fall off the end of the list of tasks, and therefore should be ignored.

In projects that I've worked on, even ones that were trying to run lean and agile, there were always bugs that weren't important enough to fix this week, but weren't trivial enough to put off fixing forever.

I have seen the dark side of the sophisticated bug-tracking system, too - projects with tens of thousands of open bugs, and a beqwildering array of settings for Priority, Severity, Fix Order, etc, etc.

Overall, I prefer that to the alternative of just throwing away information about defects.
Mark Bessey Send private email
Tuesday, April 24, 2007
 
 
> she would requisition a web cam so t

Mary is smart enough to know the resolution of a web cam is not fine enough to read print off the wall. And they can't be panned or zoomed.
son of parnas
Tuesday, April 24, 2007
 
 
It's amazing how threads get hijacked around here.  :)
TheDavid
Tuesday, April 24, 2007
 
 
Hilarious article. "If I don't know about the bugs, then they don't exist. And that means higher quality." Priceless advice!
Meghraj Reddy
Tuesday, April 24, 2007
 
 
"This is like getting a source control app for just one developer"

Source control is essential, even if you have one developer. Anybody not using source control can not be taken seriously.
Scott
Tuesday, April 24, 2007
 
 
I worked with a guy on a project who was actually so protective of "his" code that he wouldn't use source code control.  If I had to look at it, I had to ask him and he'd map a share drive so that I could edit it, and he'd set a 1-hour time limit on the share.  No lie.  There really are people that crazy out there.  I eventually learned "Do you have version control?" and "Do you use build scripts?" are absolutely fundamental questions to ask when being interviewed.
gc
Tuesday, April 24, 2007
 
 
Even if you are taking filesystem snapshots or backups, you are doing source control.  You won't have as many features, it may not work well for you and you'll spend a lot of effort on it, but if you stay in business you will be doing source control.  Better to use an off-the-shelf source control system.

Similarly for bug tracking.  If you don't track it, your users will - right away from your product.  If your product is so trivial that everything can be done the instant it is conceived and all bugs can be reproduced and fixed, that's wonderful - never seen it.  Even if you have a few different trivial products, with one suggestion each, you will need some way of tracking their roadmaps.  Or do you tell your customers - "don't tell me that bug right now, I don't track bugs, I'll call you back when I get back to that program and see if you remember."  I've used everything from email in public folders, to homegrown software to Team Foundation Server, but you have to use something.
Cade Roux Send private email
Tuesday, April 24, 2007
 
 
No, using bug tracking means you are keeping track of bugs, instead of putting them on post it notes.

In a project that I'm working on, I use a bug-tracking system, which realistically is a list of features that I should add (there are no actual /bugs/ at the moment, or usually for that matter). Many of them are minor things, and I've only got a limited amount of time to work on it - but they should happen eventually.

As for using version control - it's just so much easier, even on a single-developer projects. I've installed SVN and TortoiseSVN on my home computer. Managing these things by changing the file names - even on small projects - becomes a real bother, particularly when you do regular releases.
Jivlain
Wednesday, April 25, 2007
 
 
I don't use source control as a single developer. We have a release about every 3 months and the build process builds the product and zips the source code in one step. This is then FTP'd to a remote server for backup.

This process of zipping source code means I can still open ALL versions of ALL of my development since 1993.
Adrian
Wednesday, April 25, 2007
 
 
That is one of the most stupid, ill informed articles I've ever read. There are so many unsubstantiated claims, assumptions and ridiculous statements it's difficult to know where to begin.


"When you discover an error or get a new idea, and you can't do anything about it right now, you can at least enter it into the system. You feel a personal satisfaction that you could do something useful"

You have done something useful! You've made a note of the problem that you, or someone else can address at the appropriate time.


"the massive number of bug reports prevents your overview"

It's not necessarily massive. A tracking system precisely gives you that overview that post it notes don't! At a glance, you can answer questions like "do we currently have more bugs being reported than we can fix?", or "are the bugs focused on specific features?" Information that can help allocate resources.


"When you follow a lean development process, you have a backlog of planned tasks that will be relatively short"

I didn't realise following a lean development process went hand in hand with a failure of imagination.


"Bug tracking systems are symptoms of a heavy process"

The person designated to fix to fix the problem might be busy on another "hyper-agile,super-lean" project, or away meeting customers with the sales guy, or fixing another problem, or simply on holiday (vacation). Just because he can't address the problem as soon as it's found doesn't mean he's spending his time making his UML diagrams look pretty.


What about the situation where you have a vast amount of customers all reporting the same bug via telephone or email? At least with a bug tracking system customers might see that the bug has already been reported, when it might be fixed by, possible workarounds, add additional notes, include screen shots etc.

Having someone do all this by hand, responding the same customer queries over and over again doesn't sound very "lean" to me.


There's one thing saying something controversial to provoke discussion. It's another when it makes you look like a naive idiot.

"BestBrains" - I beg to differ.
IanH. Send private email
Wednesday, April 25, 2007
 
 
>Why shouldn't a single developer use a source control system?

Saved my bacon. Beats pawing through dozens of backup archive files (like tgz or tar.bz2 for *nix types), wondering:

"Did I put this bug into the veebelfetzer module at 2007-04-18-19-43-11 or was it at 2007-04-18-20-22-43?"

Or worse yet, wondering where the last two weeks work went to.
dot for this one
Wednesday, April 25, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz