Slashdot Mirror
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?"
Your boss is an idiot if he thinks more than one person can work on code without a revision control system and something to track defects. This is assuming yours is something more than a toy system. At a minimum, you need version control for the ability to "undo" large chage sets in case you go down a "bad path" and you need to reverse out a lot of code based on a faulty design decision or a deeply embedded bug.
Your answer seems to lie more in the political realm than the technical. Good luck.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo! http://goo.gl/J9bkO
I use RCS for everything. If the file has been edited and it was not checked into RCS, awww, shucks, your new code is gone.
IF they did use RCS and the code breaks, bingo, you can see who broke it.
I'm going to echo the quit comment.
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.
"Piter, too, is dead."
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.
Your boss is a dolt. He is an idiot. Your instincts are right. Version and defect tracking tools are very important to producing quality products. Explain to him that your department will produce better code and you all will look better if you keep track of your defects and versions. There are many benefits to using these sorts of tools, and if he doesn't want to use them, then at least you should use them for yourself. If he gets mad at you, then tell him you need it because nobody is perfect and defect tracking can ultimately make him look better and keep you happy in your job. If he says no, plan to quit and find a new job.
(My previous didnt really suggest a good solution - so here you go)
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.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo! http://goo.gl/J9bkO
...is to smile politely when they say stupid things, and then deal. I would suggest that you call your bug tracking system a "todo list" and keep a copy of the code in CVS. Produce your changes out of the CVS repository. Periodically compare what's in the head of your CVS to what's deployed, and _always_ compare before you overwrite anything that's deployed from your copy. That way you get what you want, and your boss doesn't have to deal with it. Don't tell him you have it under version control - just take advantage of the fact that you do.
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!!!
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?
the layman's guide to computer science
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.
Even better, just ignore your boss. Where I used to work, getting things done meant doing them and THEN telling management. I setup Bugzilla (+MySQL) and CVS because I needed them. I asked beforehand, "hey, can I do this", and they said it wasn't necessary. I blew them off, set it up anyway, and now people (apparently) rely on it. I got an e-mail a few weeks ago saying it was down and they didn't know how to get it back up. (Which was too bad for them -- hire someone to run it if it's important. I don't work for you anymore!)
;) That's the difference between a sheep and a genius.
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.
My other car is first.
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.
Great article on bug tracking here. Yes, he makes a bug tracker, but this article (and others on his site) goes into detail about *why* and *how*, not just "buy my product." Also good info here.
"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."
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Being a slashdot reader probably means that you're smarter than everyone else...
;-)
Oh that's too funny! You must be new around here...
I agree with the "boss is an idiot, get out" comments but suppose that you want to stay there.
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.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
"it is better to ask forgiveness than permission". put in the bug tracking, put in the version control, and if anybody ever asks you why, the answer is simple: you're doing your due diligence as a professional. if you're clever, what you'll do after three or so months is go to the powers that be and explain how you've run a successful pilot program and would like the official go-ahead to make things standard.
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.
Just run a small web server on your workstation and run the bug tracker on that. Same for running version control on it. Back it up yourself.
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.
I was in the same position, since I was the only developer for small internal applications, my superiors wouldn't allow any sort of bugtracking or versioning software, since it was seen as a waste of time and money (even if the software was free).
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.
Can't spell slaughter without laughter!
Other people have said it, but I will throw in my bit:
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.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
It seems to me this is really a non issue. First off, somehow you must do both of these tasks (track code versions and track defects) currently. Otherwise how do you get your job done? Version Control is pretty simple, just set it up. I assume you have your source in some shared area and your boss goes in and messes around from time to time in there. It is not hard to either write a script to find that or run commit from time to time from the shared dir to catch his changes. At the very least run a commit from the common area before you push out your changes to spot any potential merge issues.
I don't know how anyone writes software without version control, but I work with people who think it is not necessary. What they do is spend most of their day trying to figure out how to be more lax with this than those of us who want tighter controls (after all I don't even build my software we have a guy who does this to make sure if any of us leave the build process can repeated.) There are still problems with this as there are techniques but we are working on fixing that too. It makes me crazy when I get a demo of feature X and say I like that and the guy can't get back to X at some later point.
Now as to defect tracking... I don't think it is necessary to have a tool to track it. I work on a really big system and we have to do it becuase there are hundreds of developers who use our tools, which are developed by tens of developers across multiple timezones. No one can keep all that in their mind. But on smaller projects that we spin out we leave it up to the developers working on it as to how they will track defects. They range from complex systems that track all work to my personal small project fav "The Jahnke List (TM)." The Jahnke List works like this. I only worry about 5 things at any one time. The 5 things I work on are the 5 things people ask me the most about on that project. As such I hit the big problems lotsa little ones slip through the cracks but who cares they are little problems. I keep the list written down and in plain sight which allows folks to adjust priority and suggest things for the list.
They all work becuase people make them work. Unlike version control, which is like putting on a seatbelt. Defect tracking is more like directions on how to get where you are going. Some folks print out maps with notes on them and mark off milestones as they pass them so they know how complete they are. Others get vague idea where they are going and rely upon something to happen as they get close to get them where they need to be. After all you are looking for is the point where severe defects have fallen compared to new features as a signal to release. Most developers who work on a system have a good sense for this anyway, a defect tracker in this case makes the boss happy (it quantifies the risk aspect to compare to the reward.)
But either way in your case, since the system you currently use isn't very formal at all, adding rigor to it should not be hard without interrupting what you currently do. What gets interesting is trying to place agile methodologies into a strict waterfall process. But this is the opposite problem.
As to the folks who say quit. I must say I agree. Find a new gig, one that realizes what you do is a valuable asset that needs a minimum amount of protection. Becuase the first time things go to hell for whatever reason, you are in for a VERY uncomfortable ride, and you may be forced to look for a new job anyway, so avoid the desperation of looking for a job after having been fired/laid off/shellshocked.
Jer,
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 job and change before the shit hits the fan.
I'm personally considering the following rules when coding:
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Having been in such a situation myself a couple of years ago and looking back at it I realized that it wasn't a technical problem or whatever. It's about job responsibility. It very much depend on the way you guys work as a team on the code, even if it's a 2 man team.
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 without having the control you rightfully claim comes stress. This will come back time after time when events happen. Mild stress when small problems occur, major stress when things come crashing down. It will eat at you time and time again. Recognize this early on (It seems like you did) and set some boundaries for yourself. How much will I put up with? Then prepare a bailout plan. You may need it when the **** hits and you're kick out, or, even better, when you decide it's enough.
For me at that time it was a matter of an ever shrinking development window. It became increasingly difficult to get any requirements from the other departments before the delivery date was due. It was a good working environment, so I informed my boss I didn't want to put up with that any longer. He also wasn't in a position to change that and when the next development cycle was the same I activated my bailout plan. It was a bit scary but I landed a good job, which I still enjoy.
Bottom line is set your boundaries and be prepared to bail out.
If you don't life on the edge you take up too much space!
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.