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?"
For real.
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.
Conformity is the jailer of freedom and enemy of growth. -JFK
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."
The Army reading list
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.
If you're working for a boss that doesn't see the need for defect tracking and versioining, you're working for a boss that doesn't understand the basics of software development. Find a new job. Now. Before stuff starts falling apart and the finger of blame points at you.
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.
So your boss doesn't want to have to deal with bug tracking or version control...So make it transparent to him.
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.
tasks(723) drafts(105) languages(484) examples(29106)
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.
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.
the "i accidently pushed my boss down the stairs" plan hasn't failed me yet.
Anons need not reply. Questions end with a question mark.
Don't try to sell your boss on the idea, just install whatever version tracking tool you prefer and start using it. Install it on your dev machine if you have to and just don't tell him about it. As for bug tracking, either do the same, or just use email or a speadsheet to track bugs if you want.
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 solve the problem quickly, then consider telling your boss how you saved the time.
If you try to convince him it is a good idea after he has already knocked it on the head, you won't get anywhere.
"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.
Did you ask for $2000 worth of kit (or a few weeks of time to figure it out) to do this? Odds are, since you are the only developer, you are not working for a software company. As a boss, I'd say no *IF* you asked me to pull out my checkbook.
+++ UGUCAUCGUAUUUCU
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.
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.
ACHTUNG! Das computermachine ist nicht fuer gefingerpoken und mittengrabben. Ist nicht fuer gewerken bei das dumpkopfen.
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 that doesn't make the situation more real to you that you need to keep your resume fresh.
At the very least, this post serves as my thanks to the Slashdotters who have suggested this in the past. :)
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!
when you boss asks where a particular project is, tell him "in the version control system". make life easy -> http://tortoisesvn.tigris.org/
"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?""
Do to have any compromising photos of the boss and his secretary, you can show to his wife?
...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..
Just create a cron or at job to tar up the source once a day. Keep a couple of months' worth of backup files around (unless the source is huge). That should give you a way to get back to a working version if something goes kerplunk.
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
I had a boss who was into the same thing. I went and implemented version control and bug tracking anyway going around his orders. In my humble opinion, I think the main reason he was against this was that he was paranoid about something, I have no idea what, and because of this paranoia he had made up his mind that he didn't want any kind of paper trail as to development activities.
Once you install version control and bug tracking, make some time to teach your manager how to use them and show him how to pull statistics from them.
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 people a little while to get used to the process of using revision control and bug tracking systems. Your manager is probably reluctant beause he hasn't been shown the value and is nervous about learning something new.
I once had a boss that micromanaged me and it drove me nuts. At the end of the day, if your boss doesn't trust you to do the right thing then you need to find new work. A boss who doesn't know enough to know that he doesn't know everything is not the kind of guy you want to work for. A good boss will always grant enough trust to their employees to let them get the job done the way that they think is right.
If you don't want crime to pay, let the government run it.
Jeffrey Dalmer once wrote a book on Corporate Politics. He brought up quite a few interesting points. But, the most interesting point he made is that all conflicts should end in the freezer. What he means by this is that if your boss is giving you trouble, you need to lure him to your house with the promise of gay sex, then chop him up in little pieces and put him in your freezer. Problem solved.
I do see one problem with this strategy though. What if your boss does not like gay sex?
Well, in that case, I would suggest the training manual for the US Postal Service. They have some techniques for eliminating job problems which have proven very effective in the past. In fact, they are so effective that whenever someone uses the methods for dispute resolution, it's on the news.
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,
http://thc.org/root/phun/unmaintain.html
For what I understand, you have serveral problems :
- 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 bugs that appeared when modifying the code... but you know, you don't want to annoy him, this is not impacting his work, this is just for you... by the way, boss, why was this line of code changed ? I don't think I did, did you modify the code ?
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!
Keep opening/closing braces on their own line. - Yet another readability issue.
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 students.
Sam
blog.sam.liddicott.com
Joel Spolsky, in my humble opinion, has some excellent advice on software development culture, including some compelling arguments you might use. Here he lists the '12 steps to better code'. Arrange for you boss to read this:
0 43.html
3 32.html
... you name it, if it works and especially if it's free, use it on your code, it will only get better)
http://www.joelonsoftware.com/articles/fog0000000
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 others to start using them, and occasionaly show off your amazing documentation/source control/bug tracking system by retrieving the code the boss lost, or by producing the history of some bug or a report on bugs fixed this week.
http://www.joelonsoftware.com/articles/fog0000000
Personally I think that all of his 12 points are important and I work hard to establish these things when I start work on a new project (sometimes 'unofficially', but invariably 'unofficial' bug tracking/source control/... tools soon become official as nobody can actually live without them and remain highly productive). There are some things that I would add to his 12 points however (and this is getting slightly off topic from your discussion of bug tracking):
13. Dogmatically provide automated unit testing for all code, with as close to 100% coverage as possible; design code from the ground up to best tested
14. Always write self-documenting code (Javadoc for Java, doxygen for C++/PHP etc)
15. Use all available automated tools to improve code quality (code duplication detection, lint, valgrind/purify,
Another excellent source of advice is the Pragmatic Programmer's book, From Journeyman to Master, which discusses the practice of programming (as opposed to programming itself) in detail.
Thomas
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.
Backouts for code that's already committed? Don't need 'em much, could almost always do that as easily from a backup.
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
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.
"Being a semi-PHB myself..."
So in other words, a good answer requires having a foot in two words. Your answer also shows that any good answer requires the recognization that there's a "social component" to the problem, and not just technology is involved.
"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."
Funny you should say that. I was looking at a bug tracker/ project managment plugin for VS 2005. Plent of pretty charts and diagrams.
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 think to buy insurance for that, probably backs everything up three times anyway).
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.
Unfortunately you didn't say which platform you use so I assum it's Windows else on Linux you certainly would use CVS. On Windows you could use CVSNT (http://www.cvsnt.org/wiki/).
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
I was in a similar situation. If your boss is smart enough to write code, he is probably smart enough to see reason. You just have to have "proof" that you guys need to be using versioning etc. The problem lies in figuring out what consitutes "proof" for him. I suggest pointing out that he better have a damn good reason to go against industry best practices. During a previous stint (about 5 years) of consulting I found that using busswords like "Best Practices" when explaining this stuff to people really works. He probably won't understand at first but nobody wants to look like a dummy to his peers.
0 95419-7389469?v=glance&n=283155
:-p
Another good angle: The first principle of sales is: "The fear of loss is greater than the desire for gain." Show him what he could lose if your outfit doesn't use industry standard tools. This is probably the most reliable method to sell anything. There's also lots of studies that show projects using versioning are more productive that teams that don't use it even when versioning is implemented in the middle of a project with an aggressive deadline. Steve McConnell's book _The_Software_Project_Survival_Guide
http://www.amazon.com/gp/product/1572316217/103-2
from M$ Press has lots of usefull strategies and factoids. He also addresses the human factor in software projects. Good stuff.
He may also just not want to go through the learning curve associated with new tools. FWIW, that was part of the problem here. Using web based tools helped with user (and boss) acceptance around these parts. We're using a help desk application to track all sorts of IT trouble tickets as well as defects:
http://www.otrs.org/
OTRS (Open Ticket Request System) is an open source web based application written in PERL. So far we've had a good experience with it.
We've also implemented Subversion and Viewcvs. Both OTRS and Subversion/Viewcvs are running on a PC class box running SuSE 9.3. We're also using Very Quick Wiki:
http://veryquickwiki.croninsolutions.com/
as a easy (and quick!) way to share the progress of out software projects with the company's users. This was one of the easiest sells of all. I just installed it (very easy to install, drag and drop, uses Tomcat as server) and started using it. I sent out some project updates with a URL instead of the full text. Just pointed my users and boss toward the wiki page for the project. Now he's using it to keep notes about changes to be implemented in our enterprise systems.
Using the SuSE distro made all of this easier as all the servers (OTRS as well) are included, but your favorite distro will work just as well. We use SuSE because the last 4 or 5 versions have been well "groomed." The uptime on the box has been fantastic! Better in fact than our HP 9000's.
HTH
This sig kills fascists.
First, I would agree with most of the 'he is an idiot. quit.' comments previously posted. But let me go into some detail about a similar situation I had. I worked for a small company - the boss who could write C code, and three decent developers. The boss was a die hard 'BSD/emacs is all you ever need' type. He would do things like write his own 'toupper' because he did not know it was built into the standard library. Most of his code was thousands of duplicated lines of code with thousands of imbedded printf statements ("I don't need no stinking debugger"). His idea of version control was which laptop the code had been copied onto last. When the project became somewhat more 'official' I was able to convince him that we needed CVS and we installed it. The problem was he continued just copying files around because he didn't (want to) understand it, and it made matters worse. When his client asked about how we managed versions he went into rants about creating all 'the trees and branches for the products immediately' so he could show our expertise. I think he read an article that mentioned branches on NetBSD so we had to do them as well. This approach was reflected in the product in general. There was no plan, no architecture, no specification, things were designed and written on the fly often on the way to the customer acceptance meeting. He was used to the old ways and wasn't going to change. I eventually did quit because I felt we were delivering extremely poor product and I didn't want to be part of it. BTW, what was the product? How about the central message delivery system (pilot reports, weather notices, notices to airmen aka AFTN) for every commercial aircraft in the world. I still am afraid to get on an airplane knowing how at least one (major) part of the system was written. The bottom line is there are plenty of people out there like your boss that are in a position of power for whatever reason. You can stay and try to influence the project, or bail - but the project will probably go on, regardless.
slashdot troll = you make a compelling argument I do not like the implications of.
Rarely do things like this get done if you just talk about them... If the higher ups are ignorant of the benefits, you aren't going to convince them with words. Set up bug tracking/version control and use it. Don't speak up about it, but don't hide it either. Eventually, you'll be asked about it or you'll find an opportunity to say why these things are making life better, and that's when you do the convincing.
Amen. Too bad my last mod points just expired...
putfwd.com - 1GB Free file storage with a twist
As you are the sole developer a bug tracker might be overkill. You basically need to cordinate with yourself. Most of the need for a bug tracker system is when theres many developers who need to coordinate. Theres many other ways you could record the bugs, an 'open bugs' and a 'closed bugs' folder in your email program would do, 90% of the job.
There are four sorts of people in the world: fools, lunatics, idiots and morons. - Umberto Eco, Foucaut's pendulum.
If he does, then go over his head. Expose him for the duplicitous moron he is. And if you get fired for having some ethics (and for trying to look out for the company's interests), well, it's their loss, and your gain.
From this one can deduce that:
- Boss codes
- Boss thinks he can code
- Boss thinks he knows how to run his code shop
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 situation. It takes a sideways approach to the problem, which may result in some interesting solutions...If you don't life on the edge you take up too much space!
Start with simple no-cost solutions to code control and bug tracking, and prove the requirement to your boss by example. Be aware that you are saving them $00,000s with an in-house solution. That gives you power, so use it.
You are the one who needs to drive the specification and implementation issues, and managing those in authority is one aspect of that process.
I haven't seen much mention of project management yet apart from Steve McConnell's books, which are all practical and authoritative. Do some investigation on RAD and waterfall techniques and choose one which is simple and appropriate. I use two UK methodologies (SSADM and DSDM). Maybe other posters will have some suggestions for ones popular in the US. This stuff really helps if you use it wisely.
The time to move on is when there is nothing more for you to do, or learn. Is that the case? Juniors often get the most freedom to innovate. This may be the only job in your career where you get to make a real difference.
Subversion is nice, but Excel? If you're using MS Office you might as well use Access instead, even if it's like the suckiest database ever. In about 5 minutes you can think of all the fields you'll need and crate the tables + reliationships, another 5 to create some basic forms, and perhaps another 5 will give you some printable reports, and a last 5 for a switchboard if you really want to (Perhaps an hour tops in total if you're not familiar with it). You can import/export data to anything else (other databases, CSV, excel, etc) if you want/need to. Excel is a spreadsheet, using it for bug tracking is a very poor choice. Heck, if you want something I'll even send you a such access DB for free. Pretty much anybody will be able to use it too (coders, management, clients, etc). It has worked well for me in some situations (instead of using a real bug-tracker).
I am pretty much in your position in my company. So I do it myself. I use CVS because it is as common as mud and I think the next best source control is not there yet, but pick your own tool for the job.
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 then go to production and do a diff and check what others have been doing (It is surprising how often then do not tell you...). I accept the changes by committing to my repository adding a comment on who I think did the change and what it did or reject them by writing a note outlining what has changed and why I think it is wrong, if it is a little wrong often I patch and then commit without comment. I then update my personal working set and retest then commit again.
All of this tracking information is incredibly handy. When the investigation starts on the next major problem just diff your production working set for changes, document what has changed and how it broke. Questions will eventually be asked about how you know what is going wrong so quickly and people will move to working with you.
There will always be one person who is invaluable for the company that will stand outside the general practice. Just manage them in the same manner as best you can.
You have you bug tracking software, just keep using it eventually people will see the benifit of it, if they do not then at least you will know what is going on and be more in touch. Eventually good practice wins out.
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. With barely a hint of evangelism it took on like bush fire. Userbase is now sixty users and growing. Bug tracking is back to sanity and everyone is happy including my boss. This is my second such deployement and it worked like a charm both times. If all the projects were that easy...