Pushing the Need for Bug Tracking? 113
NorthwestWolf asks: "I am the sole developer for a medium-sized company. My work consists of developing intranet applications for the production, accounting, shipping and engineering activities at all of our locations. My dilema is that my boss is dead set on the idea that we DO NOT need a bug tracking system, nor does he feel that we have a need for version tracking. As much as I strive to write perfect code...that doesn't happen. Most recently, I asked to install a lightweight piece of bug tracking software that would not tie into the database, and was written in PHP (what our apps are already developed in). This was to be for me, and me alone; although my boss does produce some code and is the reason that I would like version tracking (he has made changes to my code that I was not aware of until I noticed problems with certain functions). So, to those of you who are, or have been in a similiar situation...what are you doing, or what have you done to get critical development tools such as these implemented at work?"
Quit (Score:2)
Your boss is a tool, and you'll end up taking the blame for whatever happens when the shit hits the fan. Unless you're "getting your ticket punched" so that you have experience for another job, get out of there tomorrow.
Re:Quit (Score:4, Insightful)
Being a slashdot reader probably means that you're smarter than everyone else... just do what your gut tells you, and others will thank you for it.
Re:Quit (Score:3, Funny)
Oh that's too funny! You must be new around here...
Re:Quit (Score:1)
Why, even slashdot readers with low (ie, 4-digit) user ids don't even seem to be able to understand subtle humour, even when a smiley is attached.
It's called Asperger syndrome [udel.edu], and it's like dyslexia for sarcasm.
Re:Quit (Score:1)
Re:Quit (Score:1)
And here I thought we were engaging in witty repartee. *lol*
Re:Quit (Score:2)
The costs of version control (Score:3, Informative)
And there, I think, is the crux of why management might resist version control in the first place: support costs. It's fine as long as you're there, but now you're not they need to find someone else to support it or else the business is completely blocked. Of course, you won't get any argument from me that version control software is essential for any professional software development, but I can certainly see ma
Re:The costs of version control (Score:2)
In that case, leaving might not be a bad idea. If your company
Re:Quit (Score:3, Informative)
Another thought, as well: there may be a good chance your boss simply doesn't have the background needed to understand a good way to use versioning or bug tracking. He may not want them because he is scared he'll look foolish if you install them and he doesn't know how to use them. Maybe
No offense meant but... (Score:4, Insightful)
Your answer seems to lie more in the political realm than the technical. Good luck.
Re:No offense meant but... (Score:5, Insightful)
Heck, I think I'm a pretty good coder but I wouldn't work on anything non-trivial by myself without some sort of versioning.
Re:No offense meant but... (Score:1)
Difference oriented programming (Score:2)
Version tracking (Score:2, Interesting)
IF they did use RCS and the code breaks, bingo, you can see who broke it.
Quit -- (Score:3, Funny)
Use bugzilla and subversion; both free, both easy and serviceable out-of-the-box (except no box in their case)
Install them on a piece of crap system with debian stable and don't tell your boss they are there.
If he fires you, tell your new boss during the interview that you were terminated for using bug tracking and version control.
If you're too afraid, stay there, and do every single damn thing your boss tells you to.
Again, quit. Your boss is not respecting your professional opinion.
Re:Quit -- (Score:1)
Re:Quit -- (Score:1)
Re:Quit -- (Score:3, Insightful)
Sometimes being a professional is hard.
You may have to subtly introduce ideas and not worry about getting credit.
Depending on the size and culture of the company making changes can range from demonstrating it first, doing it and asking for forgiveness later, to even subtly mentioning some ideas to the right person and allowing them to later "have a great idea" that you can implement.
Find another professional who you respect, they don't need to be a developer but it is preferable that they can g
Bugzilla (Score:3, Informative)
IMHO bugzilla is total overkill for small internal use. Mantis is way easier to setup and work with.
Re:Bugzilla (Score:4, Informative)
Since I knew the client was going to be entering bugs as well (during alpha and beta stages), and that Bugzilla is a pain in the ass for the developers themselves to use, I decided to grab a copy of Mantis, which I had used at a previous job and knew had a fairly simple interface that non-techs would be ok with.
The next thing you know, our project manager was exclaiming "How in the hell did you manage to find and install a tool that 1) People are actually USING to log bugs, 2) Devs are updating with notes and status CONSISTENTLY, and 3) Management and the client are using to see where things are???".
She was shocked (hey, a lot of companies have trouble getting buy-in and usage for tools) and after that project, Mantis became the standard in-house Bug Tracker. We modified it to suit our needs for some other tasks, and it is now a make-shift trouble ticket system too, though some of us would rather move back to RT for that, and use Mantis soley for bugs. But at least it's used, and is a major tool in the chain. All change control info is in there.
Sounds like you need unit tests, too (Score:2)
Re:Sounds like you need unit tests, too (Score:1)
Re:Sounds like you need unit tests, too (Score:1)
> Ruby)....the response I got...well let's just say we had a
> discussion about what unit tests are
Hehe... classic. Well, best of luck!
Suggestions (Score:2, Informative)
There are tons of good bug trackers out there. I like Mantis [mantisbt.org].
Re:Suggestions (Score:2)
Subversion is definitely the way to go over CVS. I've recently set it up on RubyForge and it's much more popular [blogs.com]. Being able to actually rename files and move them around, good times. Not to mention atomic tagging and commits!
Re:Suggestions (Score:2)
cvs was nice and had it's moments, but if you try subversion for once, you won't go back to cvs.
running around without a version control is indeed insanity. i know people that keep their mud clients rc files in cvs, and that is a lot less important than anyone's production code
Complete dolt... (Score:3, Insightful)
Possible solution (Score:5, Insightful)
Try introducing your boss to "quality measures" as detailed in any number of Software Engineering texts. have him read any number of the good books on software production. Let him realize that rework costs money - and that repeated rework (i.e. fixing bugs that were fixed before) can become exponentially more expensive in terms of the time (i.e. money) that you have to spend on such activities. Furthermore, the lack of source code control prevents you from recovering quickly from coding errors - your or his.
In business terms, perhps this would sell it: there is no *accountability* for errors or defects, no way to list and prioritize activity you need to take with defects, no ability to see trending or patterns, no ability to learn from your errors and prevent future ones, etc. No way to manage the process wth any sort of efficiency or effectiveness.
Basically making software without bug tracking and version control is like running the cash side of the business without any accounting system. And its simply unprofessional.
If this doesnt do the trick, then you need to get out. Sooner or later he will make a change to the codebase that will break things in the fuiture, and you will have no way to unwind it short of a full rewrite. And without bug tracking and version control, it will all be blamed on you, and you will get stuck with the blame, the loss of trust, the downtime for repairs and the overtime charges needed.
Re:Possible solution (Score:2)
Having been in a very similar situation, I can tell you exactly what the response would be:
I don't make any errors and if you do, you should try harder!
Very true. Of course, bug tracking
The way you deal with morons... (Score:5, Insightful)
Re: (Score:2)
Re:The way you deal with morons... (Score:2)
Re:The way you deal with morons... (Score:2)
Don't tell him you have it under version control - just take advantage of the fact that you do.
Don't try to hide it, either, though. If (when) the subject comes up, simply tell him that it makes you more productive. I always use version control even on one-man projects because (a) it's often useful to be able to refer to the history and (b) it gives me more freedom to experiment with significant changes, since I can always roll them back, or even develop them on a separate branch. As far as the bug tr
Re:The way you deal with morons... (Score:2)
Find a new job. (Score:2)
not using version control is utterly stupid (Score:3, Informative)
How do you experiment with new versions? How do you try out a new idea and then throw it away?
How do you work with multiple people? How do you track who did what? Hell, how do you see your own day-to-day changes? I edit my programs, I change a few files here and there, then I run cvs diff to review what I did. I can't imagine working without that.
Suppose your software ends up being useful for a client, and you have to maintain two versions? How do you do that without version control?
How do you copy your code to multiple locations? My apps are checked out on my powerbook, my desktop, the staging server, etc., etc., I can't imagine how I'd work from multiple locations without it.
I think I read somewhere that writing code with version control is like a word processor without an Undo feature
I would recommend either quitting (your boss is clearly gonna drag you down one way or another) or setting up simple version control (CVS, Darcs, SVN) and just using it yourself and checking his changes in yourself. I.e., use rsync or something to keep your "master code base" in sync with a local workspace. It will save your ass on many occasions, as well as allow you to experiment, and your boss doesn't have to know the difference.
As for bug tracking, well, we don't use any special program. To track bugs we just post messages in Basecamp (www.basecamphq.com) and refer to the URLs in the check-in log. This might be good enough for you. You could set up a message board or Wiki for this purpose.
But damn, no version control.. like I said, inconceivable!!!
Re:not using version control is utterly stupid (Score:2)
If you've used version control for as long as you remember, of course you'll see the need and benefit. To someone who's never used it, they need to see WHY they should use it. The introductory chapter from any book on version control should help quite a bit here (I really like Practical
I'm shocked (Score:3, Interesting)
Really shocked.
I mean, there are a lot of hobbyist coders out there that don't use revision control software, for whatever reason. There are also, it would appear from previous Slashdot stories, a great many (big name) companies out there that don't use revision control software.
I have never heard of anyone being forbidden to use revision control. And, for something that actually gets deployed (as your code presumably does), no bug-tracking facilities seems equally staggering.
Has your boss given you any indication why he doesn't like these (what I would regard as necessary) tools of the software engineering business? To follow up on what another poster mentioned, is he also against accounting software/books for keeping a tally of income and outlay? Does everything go through petty cash and little scraps of paper with IOUs printed on them?
How on earth can this possibly work out?
Re:I'm shocked (Score:2)
When I suggested to m
Get out of your mother's basements, people (Score:5, Insightful)
You can see that the stereotype of slashdotters living in their mother's basements until they are 35 isn't too far off the mark by all the comments here. Every other reply is "Quit. You are smart and he is dumb. Just quit." That's easy to say when no one is depending on you. It's another thing entirely if you have a wife and kids to support. I know this is difficult for some of you, but just picture what it might be like if you actually had someone (other than your mother) who cares about you:
Loving wife: "Hi Honey. How was your day?"
Slashdotter: "I quit my job."
LW: What? Why? Whatever for?
S: The boss wouldn't let me install Subversion.
LW (pausing for a few seconds in disbelief): Honey, I don't know what a Subversion is but I do know that Jenny's orthodontics bill came in the mail today and that the mortgage payment is due next week. You need to go down there and tell them it was all a big mistake and that you'd like your job back. Our family is depending on you!
S: Hey, the guy's an idiot. It's not enough that the boss chews me out for reading Slashdot at work, you've gotta get on my case too? I'm going to play Unreal Tournament. Just leave me alone for awhile.
LW: Mother was right. I should have married Dirk instead!
Guys, enough of this sorry "If you can't have everything you way you want it, then quit" crap. This guy needs some real advice.
the unspoken assumption... (Score:1, Insightful)
Re:Get out of your mother's basements, people (Score:2, Informative)
One more suggestion (Score:2)
Hopefully seeing the value of the statistics and an example of tracking changes and how you can back out a buggy change several revisions ago will change his mind.
If not, you might need to set up a seperate branch and an automated nightly diff/copy/submit that will automatically pull in changes that your manager makes to code stored on a share.
It takes some pe
Re:Get out of your mother's basements, people (Score:2)
Re:Get out of your mother's basements, people (Score:1)
Obviously none of the posters here are seriously suggesting the OP just quit immediately over this issue.
Re:Get out of your mother's basements, people (Score:1)
A very drastic comparison, I know, but mate, there is just so much one can take and deal with. If there are, or were no consequences for bad behaviour, we would all be f.....
I'm tired of sorry ass excuses. This is just one of them. Do you really think he will be able to support his family, once the company goes bust, and he's trying to get a new job? Does take your life into your hands mean anything to you?
At least you got mod
Re:Get out of your mother's basements, people (Score:2)
You might not be aware that some people have very few expenses. If you're 21 and just out of college, you'll probably be living in a not-too-expensive apartment with a roommate. This makes rent like $300 a month, even in the city. Add in another $100 for utilities and $200 for foo
Implement it surrepticiously? (Score:1)
Put your code on a filesystem that has built-in version control, and put it all on a server. Windows shop? No problem...share the filesystem with Samba.
Anyone know of a Subversion client with a FUSE front=end?
As for bug tracking, that's probably harder. Just add that to your list of responsibilities, if it's important enough to you. At least you'll have record.
Re:Implement it surrepticiously? (Score:2)
Read-only unfortunately, but actually, that's quite useful for publishing a subversion repository to a webserver and *forcing* people to check changes into the repository to make them go live.
Re:Implement it surrepticiously? (Score:1)
As long as his boss uses the subversion filesystem, and he uses a direct client, then he'll know where changes came from, right?
Re:Implement it surrepticiously? (Score:1)
Re:Implement it surrepticiously? (Score:1)
Joel! (Score:3, Interesting)
"If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally."
Re:Joel! (Score:2)
I'm gonna get troll-tagged into oblivion for this, but here goes nothing:
Joel's argument is a platitude at best, and a fallacy at worst. He is plying his trade, no mistake about it: "Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time". Nonesense? Joel, buddy, casuistics ain't argument; what's good for you is... well, just good for you, not justification for anything. If you can't remember your name on odd days, it doesn't m
Re:Joel! (Score:2)
Quit but before that... (Score:4, Insightful)
Implement a version control system yourself on your desktop computer. Create/install/implement a bug tracking system for yourself. Use them like a nazi.
At the very least, you can do this at your own pace, get experience in doing it, learn what you like/dislike about your system (extra bonus: partcipate in version-control system flame-wars!) and can fix it as you go without others crying about it. Make proper backups on a regular schedule and learn how to restore them.
Take advantage of the fact that you are a big fish in a small bowl.
a sweet plan (Score:1)
BTDT (Score:1)
When something goes haywire (and it will, especially if he is making code changes without telling you about them) you will be able to refer to your version control and/or bug tracking system. If the tools help you s
as grace hopper said: (Score:3, Insightful)
if you're a little less bold, call a meeting and pitch it to your boss (and his bosses). estimate how much time (and, as a result, money) the issues you described cost the company. explain how much implementing the stuff you're asking for will cost the company. the key words are: risk management, due diligence, and the potential impact on insurance premiums (you'll have to check into this one, but where i work, the fact that we replicate our cvs server every two hours and have weekly backups for the past three years on-site and for the past several months offsite means that we get quite a pleasant cut in our premiums). if this doesn't work, i think it's time to start shopping your resume around, because it shows that management's head is in completely the wrong place.
Insurance? was Re:as grace hopper said: (Score:1)
What exactly are you insured against?
Just curious... I've never heard of any insurance against not having proper backups, and I'm not sure if it would be very expensive (since anyone who would need it is obviously not maintaining their backups), or very cheap (since anyone who would thin
Re:Insurance? was Re:as grace hopper said: (Score:2)
Re:Insurance? was Re:as grace hopper said: (Score:1)
Re:Insurance? was Re:as grace hopper said: (Score:2)
$20 question... (Score:2)
Do it anyway (Score:4, Insightful)
If it doesn't affect anybody else and it improves your productivity, I don't see any reason why you even have to get your boss's permission. Especially if you're the only developer so you don't need to have anybody else also working with these tools.
Excel and Subversion are your friends (Score:1)
For version control, you can't beat subversion, it can be set up in about 15-30 minutes in Unix, Linux, or Windows, and it's dead easy to use.
Are there better tools? Sure, but none are this simple, and when your (short-sighted) boss gets on your case, you can honestly tell him it took only 30 minutes to set up.
Re:Excel and Subversion are your friends (Score:3)
Subversion or CVS as version control is about the same when it comes to a small project. Subversion is the successor to CVS and should normally be the choice unless there are other factors that makes it hard to implement.
Obviously - the boss in question is probably also rejecting ISO 9000. And I even wonder about what the accounting looks like. So it may be a good idea to silently look for another jo
formatting rules (Score:2)
also one of dispite; I prefer it the other way:
if (blah) {
something();
} else {
somethingElse();
}
However, without getting into a holy war over it, the less information each source line contains, the bigger your diff context needs to be when patching, or the more likely you are to run into patch ambiguities later,
How much bigger the diff context needs to be is left as an excercise for information theory
Re:Excel and Subversion are your friends (Score:2)
i've reached a point where i run whatever project i'm working on through valgrind at least once every two weeks and usually more often than that (before every non-trivial commit). i
Re:Excel and Subversion are your friends (Score:2)
* the entry point of the application
*/
main () {
doThings();
}
Re:Excel and Subversion are your friends (Score:2)
Should read: "Each method/function shall have a comment describing that method/function"
Re:Excel and Subversion are your friends (Score:2)
Re:Excel? (Score:1)
HR documentation (Score:2)
If you have an objection to managerial policy, document the situation and your objection with Human Resources. Take the advice everyone else given here regarding the estimation of time/money lost and of unaccountability and unprofessionalism, make your presentation, and file it with H.R. Then see if
Take Matters Into Your Own Hands (Score:4, Interesting)
I didn't really care until my code started getting changed by other people - other people (I won't use the word developer since I was really the only coder) that thought they knew what they were doing.
I started off by changing permissions on directories so that no one else had access. But the permissions would be reset by the admins so that the files could be edited. Then I started making daily archives and hashing them, and it worked for a while, but was a hassle. So I started keeping detailed records of time spent fixing the changes. During our weekly team meetings, I started revealing just how much time was spent fixing other code changes. The changes stopped for a while, but resumed.
So one day, I "accidently" lost the entire codebase. And preached that versioning software would have allowed me to pick up where the loss happened.
As for bug tracking, I had to write my own system that was hosted locally (via an illicit install of cygwin/apache/mysql/php), just to track them. One day, my boss accidently saw it and thought it was the greatest thing since slided bread and wanted everyone to use it. I quickly got rid of it off the work machine, but soon we had bug tracking software and my boss was praised by her superiors for her innovative thinking.
Re:Take Matters Into Your Own Hands (Score:2)
Gah. A version control system, even if it is a weenie one like MS VSS, is one of the basic things separates amateur coding for fun from professional software development.
"Source control is like flossing - you don't have to floss *all* your teeth - just the ones you want to keep." - Dave Scofield, Borland
I had to write my own system
You shouldn't need to write anything - you just need to get the hardware and time to install subversion [tigris.org]
Re:Take Matters Into Your Own Hands (Score:1)
Oh, I agree, both packages are superb. I used cvs for versioning and my little homebrew for bug-tracking. It was a rather pathetic system - no multi-user support, limited assignment ability, no reporting, - but it worked for me to be able to record what I needed to know so I could work. It was more for my own personal use to keep track of things than for any sort of professional wide-sprea
shoot first, ask questions later (Score:2)
when you boss asks where a particular project is, tell him "in the version control system". make life easy -> http://tortoisesvn.tigris.org/ [tigris.org]
Reiteration of comments (Score:3, Interesting)
If your boss is against source/change management software, just use it for yourself.
After all, you spelled it out in your opening post: "As much as I strive to write perfect code...that doesn't happen." The hell with protecting yourself from your boss; protect yourself from YOU on the occasions where you discover your thumb is mysteriously parked up your bottom.
As an aside: I work at a place where I get to watch my clients trip over their own mistakes and come up to me, hat in hand, asking if *I* happen to have a previous version of their object code. Bad times all around. This is a crappy position for me to be in, and the silly fact is that it isn't my ass if the code is broke. The position of the dude who has to ask me if I might have the last version of his code has to be at least three times worse.
Boss is nuts, trying to hide something or both (Score:2)
Micromanagement (Score:2)
It is always easier to be more strict... (Score:2, Insightful)
I bet your boss's code matches this (Score:1)
Introducing your tools, then prove it works (Score:1)
- Tracking the bugs
- Tracing the code
- Working with your boss
Once it seems convincing your boss is the most difficult task, you may act this way
- Just install the bug tracking system on a server, or may be on your own PC, for your own need. Just enter your bugs inside, track them, don't show it... yet.
- Same thing for the code, if you can. Just install svn.
Then, a few months later, and by accident, show your boss the bugs that are still alive, and the bug
Not a technical problem (Score:2, Insightful)
If there's an atmosphere of free and open coding, with shared responsibility (both in the mind and when the **** is hitting the fan) then it just has to feel like the way you want to work. If the responsibility is on your shoulders, then witho
Try Joel Spolsky's articles on this problem (Score:1)
http://www.joelonsoftware.com/articles/fog00000000 43.html [joelonsoftware.com]
If that doesn't work, I would recommend reading his article 'getting things done when you're only a grunt' - basically, it says that you should just go ahead and set these things up for your own use, and then maybe even get oth
How to sell to PHBs (Score:3, Informative)
If the bug tracking system can be deployed using existing resources and is free, then all you have to do is to show that its value is anywhere above zero for the cost-benefit angle to work itself out. There are mature open source bug tracking systems which don't take more than a half an hour to install and another hour to read up on and begin using, this also needs to be highlighted (i.e. to show that it won't take too much of your time which equates to the company's money).
Make accounts for the PHB, read only access if possible. Show them the fancy stats page where there's pie charts and statistics relating to bug fixing performance.
Find some trivial system the PHB uses and enter it as a product on the bug tracker and have the PHB use it; that gives them a sense of involvement and empowerment.
Brand it with the company logo, license permitting.
It amazes me how 67 replies can all miss the point (Score:2, Informative)
Nobody here has addressed the underlying issue - you're the ONLY developer and yous boss doesn't listen to your opinions on basic and obvious issues? This says one of two things:
a) your boss is a complete tool (well covered but beside the p
Re:It amazes me how 67 replies can all miss the po (Score:2)
Re:It amazes me how 67 replies can all miss the po (Score:1)
From this one can deduce that:
As a boss he needs to be convinced he is capable of doing all this, of course, so it takes a lot more than just balls to alter this
This worked for me (Subversion and OTRS) (Score:2)
Similar experience (Score:1)
If possible, just do it (Score:1)
A Bug Tracker might be overkill (Score:2)
Does your boss have a boss? (Score:2)
Re:Does your boss have a boss? (Score:1)
>company's interests), well, it's their loss, and your gain.
I'd think getting fired would be his loss as well.
Re:Does your boss have a boss? (Score:2)
Seriously, would you want to be known as a toady for this guy's boss?
Do source control yourself (Score:2)
I run production as a working set (a check out). When people copy in 'their version' of code into the working set then it is an update and I can see the changes that they have made (and undone other work).
I have my own working set on my computer, I make my changes and test, commit to the repository. I th
Done it... (Score:2)
I started a new job this summer. First shock was to discover that bug tracking was handled with assorted spreadsheets all subtly different and a sprinkle of randomly formatted mail. Just reporting bugs and worse, gathering information about them was driving everyone crazy. I promptly took the initiative to write requirements and implement them by installing and parametering Mantis [mantisbt.org]. With barely a hint of evangelism it took on like bush fire. Userbase is now sixty users and growing. Bug tracking is back to s