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
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.
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.
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.
...was that he quit and get another job. See, that solves that problem. Usually it's "look for job first at any indication you will be quitting", for whatever reason that might be. Another assumption but usually the default behavior of most rational people. It's getting fired that usually causes more economic grief, because it could be quite unexpected. In this situation, the author has the upper hand, even though he has a problem, he has an option to not deal with a knucklehead and thereby solve one real time problem, and probably several future problems. any coder boss who doesn't appreciate versioning control is bound to be making more critical business mistakes, so it is a good bet to bail out early..
Have courage.
...oh, and don't quit yet, you might find that you are in a perfect position to grow your leadership potential.
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 grok technology and your work situation and that they don't report to anyone near your manager. Ask them if they would mentor you and have weekly or monthly coffee with them so you can bounce ideas off of them.
In the long run, their advice will be much better than what you get on Slashdot!
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,
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!