Pushing the Need for Bug Tracking?
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?"
Subversion for source control. (The Eclipse development platform has plugins for PHP and Subversion.)
There are tons of good bug trackers out there. I like Mantis.
It's inconceivable to me how anybody could write code without version control. Sure, maybe a throwaway script or two, but even my shortest simplest programs are in CVS or darcs (darcs is great for individuals, btw, as well as teams).
.. if you make a mistake, you have to remember how it was and manually put it back. Yuck!
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!!!
This is an excellent point. You're responsible for keeping all the chickens in the coop and well behaved, but your boss keeps opening up the gate, taking eggs, and letting them out -- and then YOU have to take the blame.
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 you could work out some scripts and aliases that you could set up to make them work simply and easily and let him see how easy they are to use. If he can do it without feeling like an idiot or being afraid he's doing something wrong, he might change his mind.
But if that isn't the case, he's holding you responsible for mistakes he may make and you're better off working somewhere else before his ID-10T errors fsck up YOUR resume.
Thanks for uderstanding my situation, although I think that quite a few of the "quit" responses are more based on an emotional reaction rather than a cool and collected state of thinking. Yes I do have a family, no kids, but a soon-to-be wife and a few animals that might as well be my kids. I think that after looking at and considering all of the posts here I am going to be running Apache off of a box that doesn't see much use and run my version tracking and bug tracking software off of that. At very least it creates a level of accountability for changes made to the codebase.
Being a semi-PHB myself...
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.
Blearf. Blearf, I say.
IMHO bugzilla is total overkill for small internal use. Mantis is way easier to setup and work with.
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 management's point of view. What the OP needs to do, and what you perhaps should have done, is give a proposal in terms of the financial benefit vs. the estimated loss caused by untracked faults, etc.
At my place of work we use Subversion, but most of the other staff seem incapable of using it correctly. They'll work for a week and then commit all of their changes in one go, completely defeating the object of the revision log. It's important to remember that not all developers are familiar with version control, and developers might have to adapt their workflow which may cause a productivity hit and thus additional cost in the short term.
I've been a regular slashdot reader for a while... but I read this article and had to sign up immediately to post a reply. This poor guy desperately needs some tough love and everyone here is jumping on the pity bandwagon and feeding him bull****. Here's my 2 cents:
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 point since you can do NOTHING about it)
b) you're afraid of conflict and don't know how earn his respect (something you CAN change)
I'm going to suggest something harsh - the issue here isn't bug tracking, or your manager being a tool, or looking for a better job, it's YOU. Clearly you're in a position where your manager doesn't know what he's talking about and you do. So why are you letting him tell you what to do? It's obvious to me that you don't know how to communicate with him in a way that commands respect and attention, and you seem to think you have no power in this situation.
You have to grow some balls and learn to stand up to the guy. Be mature, walk in and tell him with a straight face that you NEED this software (and if you want, BRIEFLY list the reasons why it is necessary). Don't let him argue with you, you're RIGHT. Then just DO it - install the freakin' software! It's not costing your boss a damn cent, and will probably save him money down the road. Do this in the future ANY time you are completely sure of something and you KNOW you're right about it. Your boss will react in one of three ways:
a) arguing or reprimanding you for your conduct (in which case you might as well look for a new job since you have ZERO respect here and never will, dooming your career to countless incidents like this)
b) threatening to or actually firing you (VERY unlikely since you're their only developer, but probably not a bad option - see point (a) and add a severance package)
c) backing down (thus earning you some desperately needed respect and allowing you to work effectively)
The point is you need to learn to be assertive. Stand up and voice your opinions in a confident way.