Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Businesses Programming IT Technology

Pushing the Need for Bug Tracking? 113

Posted by Cliff from the persuading-management-for-the-right-tools dept.
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?"
This discussion has been archived. No new comments can be posted.

Pushing the Need for Bug Tracking? More

Pushing the Need for Bug Tracking?

Comments Filter:
  • 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.

    • Re:Quit (Score:4, Insightful)

      by jrockway ( 229604 ) * <jon-nospam@jrock.us> on Wednesday December 28, 2005 @10:53PM (#14355723) Homepage Journal
      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!)

      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. ;) That's the difference between a sheep and a genius.

      • Re:Quit (Score:3, Funny)

        by arb ( 452787 )
        Being a slashdot reader probably means that you're smarter than everyone else...

        Oh that's too funny! You must be new around here... ;-)
      • This is good advice. I installed CVS without talking to my boss about it. Then one day a hardware problem crops up and he wants to know whether it could be software. Instead of chasing potential wild geese through the code, I just drag up an earlier version from CVS that we know works and test 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.

        And there, I think, is the crux of why management might resist version control in the first place: support costs. It's fine as long as you're there, but now you're not they need to find someone else to support it or else the business is completely blocked. Of course, you won't get any argument from me that version control software is essential for any professional software development, but I can certainly see ma

        • > 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.

          In that case, leaving might not be a bad idea. If your company

    • Re:Quit (Score:3, Informative)

      by TheWanderingHermit ( 513872 )
      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

  • No offense meant but... (Score:4, Insightful)

    by EQ ( 28372 ) on Wednesday December 28, 2005 @10:18PM (#14355538) Homepage Journal
    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.

    • Re:No offense meant but... (Score:5, Insightful)

      by pthisis ( 27352 ) on Wednesday December 28, 2005 @11:57PM (#14356014) Homepage Journal
      Your boss is an idiot if he thinks more than one person can work on code without a revision control system

      Heck, I think I'm a pretty good coder but I wouldn't work on anything non-trivial by myself without some sort of versioning.
      • I second that... I am currently in school, and I keep all of my source code, homework, websites, and my system config in subversion. Plus, it makes backups REALLY easy; tar up the repository, compress and PAR it, burn it onto a CD, and I have backups of not only the most recent version, but every version since I started. And it's hard to forget to include something in the backup.
    • I use version control religiously and have done so for over a decade. What I find useful about version control is a few different things:
      1. Difference display. I can see what changes I am making *before storing them*. This let me review code and I usually cut down any change to be a single logical change per commit, to be able to review it. If I have changes in my tree that's multiple logical changes (e.g, mixed whitespace changes and code changes), I take out a diff and massage it to be a single logi

  • Version tracking (Score:2, Interesting)

    by Anonymous Coward
    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.

  • Quit -- (Score:3, Funny)

    by chris_mahan ( 256577 ) <chris.mahan@gmail.com> on Wednesday December 28, 2005 @10:24PM (#14355571) Homepage
    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.

    • If you can implement what you want with a minimum of effort/hassle, then do so whether your boss likes/endorses it or not. Keep it off-site if you must. Hell, even stock up on half a dozen flash drives and do it THAT way if you have to! And the first time it saves your/the company's bacon, make damn sure your boss KNOWS IT. Then hand him a requisition for whatever you need to properly implement what you NEED and compare that with the cost to the company as calculated by ($$$ lost per hour) * numberof ho
    • The issue of respect for my professional opinion has been creeping up on me for awhile...but I am trying to do what I can being in the position that I am as the lone developer to bring about changes that will benefit to company and bringing about those changes in a manner that ensure I am the only one who can and will get credit for it.

      • Re:Quit -- (Score:3, Insightful)

        by deranged unix nut ( 20524 )
        Have courage.

        Sometimes being a professional is hard.

        You may have to subtly introduce ideas and not worry about getting credit.

        Depending on the size and culture of the company making changes can range from demonstrating it first, doing it and asking for forgiveness later, to even subtly mentioning some ideas to the right person and allowing them to later "have a great idea" that you can implement.

        Find another professional who you respect, they don't need to be a developer but it is preferable that they can g

    • Bugzilla (Score:3, Informative)

      by marcovje ( 205102 )

      IMHO bugzilla is total overkill for small internal use. Mantis is way easier to setup and work with.

      • Re:Bugzilla (Score:4, Informative)

        by mbadolato ( 105588 ) on Thursday December 29, 2005 @11:23AM (#14358136)
        Quite true. Last year, I lead a team on a MAJOR project for a huge client. At that point our department didn't really have a good bug tracker in place, though some were toying with setting Bugzilla up.

        Since I knew the client was going to be entering bugs as well (during alpha and beta stages), and that Bugzilla is a pain in the ass for the developers themselves to use, I decided to grab a copy of Mantis, which I had used at a previous job and knew had a fairly simple interface that non-techs would be ok with.

        The next thing you know, our project manager was exclaiming "How in the hell did you manage to find and install a tool that 1) People are actually USING to log bugs, 2) Devs are updating with notes and status CONSISTENTLY, and 3) Management and the client are using to see where things are???".

        She was shocked (hey, a lot of companies have trouble getting buy-in and usage for tools) and after that project, Mantis became the standard in-house Bug Tracker. We modified it to suit our needs for some other tasks, and it is now a make-shift trouble ticket system too, though some of us would rather move back to RT for that, and use Mantis soley for bugs. But at least it's used, and is a major tool in the chain. All change control info is in there.
  • he has made changes to my code that I was not aware of until I noticed problems with certain functions
    Of course, if your boss is opposed to version control, I can only imagine what he'd say about writing automated test code. Or worse yet, static analysis [blogs.com]! Yikes!

  • Suggestions (Score:2, Informative)

    by hhlost ( 757118 )
    Subversion [tigris.org] for source control. (The Eclipse development platform [eclipse.org] has plugins for PHP [phpeclipse.de] and Subversion [tigris.org].)

    There are tons of good bug trackers out there. I like Mantis [mantisbt.org].
    • > Subversion for source control.

      Subversion is definitely the way to go over CVS. I've recently set it up on RubyForge and it's much more popular [blogs.com]. Being able to actually rename files and move them around, good times. Not to mention atomic tagging and commits!
      • indeed, go for subversion.

        cvs was nice and had it's moments, but if you try subversion for once, you won't go back to cvs.

        running around without a version control is indeed insanity. i know people that keep their mud clients rc files in cvs, and that is a lot less important than anyone's production code ...

  • Complete dolt... (Score:3, Insightful)

    by CokoBWare ( 584686 ) on Wednesday December 28, 2005 @10:29PM (#14355604)
    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.

  • Possible solution (Score:5, Insightful)

    by EQ ( 28372 ) on Wednesday December 28, 2005 @10:29PM (#14355606) Homepage Journal
    (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.

    • Furthermore, the lack of source code control prevents you from recovering quickly from coding errors - your or his.

      Having been in a very similar situation, I can tell you exactly what the response would be:

      I don't make any errors and if you do, you should try harder!

      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.

      Very true. Of course, bug tracking

  • The way you deal with morons... (Score:5, Insightful)

    by mellon ( 7048 ) * on Wednesday December 28, 2005 @10:31PM (#14355613) Homepage
    ...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.
    • Comment removed based on user account deletion
      • RE Version control - I remember back around, oh, 1995, I was working in a shop with no version control, and the boss refused to shell out the cash small amount of cash - 3 of us in the department (2 consultants and myself) just bought it on OUR dime, and installed it - and did not tell him about our productivity increase - what was good about this is he would give use a deadline - which always required OT - and we would be working a lot LESS unpaid OT - was well worth the cost

    • Don't tell him you have it under version control - just take advantage of the fact that you do.

      Don't try to hide it, either, though. If (when) the subject comes up, simply tell him that it makes you more productive. I always use version control even on one-man projects because (a) it's often useful to be able to refer to the history and (b) it gives me more freedom to experiment with significant changes, since I can always roll them back, or even develop them on a separate branch. As far as the bug tr

    • Or you could find an employer that doesn't have conflicting ideas. Probably a better thing to do in the long run.
  • 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.

  • not using version control is utterly stupid (Score:3, Informative)

    by Anonymous Coward on Wednesday December 28, 2005 @10:43PM (#14355667)
    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).

    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 .. if you make a mistake, you have to remember how it was and manually put it back. Yuck!

    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!!!
    • Many shops/lone coders/projects operate w/o version control simply out of ignorance - they just don't know that it's out there, or don't see an application for it in their process. Others are just plain intimidated by it.

      If you've used version control for as long as you remember, of course you'll see the need and benefit. To someone who's never used it, they need to see WHY they should use it. The introductory chapter from any book on version control should help quite a bit here (I really like Practical

  • I'm shocked (Score:3, Interesting)

    by Ithika ( 703697 ) on Wednesday December 28, 2005 @10:44PM (#14355679) Homepage

    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?

    • Years ago the company I work for bought another company which marketed a competing device. The direct impact for me was that I got a new boss (from the other company) and I had to maintain the code for the device. The previous version control system was a combination of a make file which built everything and shell script which tarred & zipped everything and gave a name with the date embedded. So I got a stack of CDROMs and a clunky UNIX workstation with thousands of tar.gz files.

      When I suggested to m

  • Get out of your mother's basements, people (Score:5, Insightful)

    by Anonymous Coward on Wednesday December 28, 2005 @10:51PM (#14355713)

    You can see that the stereotype of slashdotters living in their mother's basements until they are 35 isn't too far off the mark by all the comments here. Every other reply is "Quit. You are smart and he is dumb. Just quit." That's easy to say when no one is depending on you. It's another thing entirely if you have a wife and kids to support. I know this is difficult for some of you, but just picture what it might be like if you actually had someone (other than your mother) who cares about you:

    Loving wife: "Hi Honey. How was your day?"
    Slashdotter: "I quit my job."
    LW: What? Why? Whatever for?
    S: The boss wouldn't let me install Subversion.
    LW (pausing for a few seconds in disbelief): Honey, I don't know what a Subversion is but I do know that Jenny's orthodontics bill came in the mail today and that the mortgage payment is due next week. You need to go down there and tell them it was all a big mistake and that you'd like your job back. Our family is depending on you!
    S: Hey, the guy's an idiot. It's not enough that the boss chews me out for reading Slashdot at work, you've gotta get on my case too? I'm going to play Unreal Tournament. Just leave me alone for awhile.
    LW: Mother was right. I should have married Dirk instead!

    Guys, enough of this sorry "If you can't have everything you way you want it, then quit" crap. This guy needs some real advice.

    • the unspoken assumption... (Score:1, Insightful)

      by Anonymous Coward
      ...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 t
    • 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 lea
      • 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 pe
      • The "quit" suggestions aren't entirely wrong... if they actively try to prevent you from using version control, that means you work for dolts. Working for dolts can pay the bills, but the smarter the management is, the more likely a company is to survive. Working in a stupid company that's not a monopoly tends to be less secure than working in a smart one. (monopolies, like power and water companies, can get ridiculously stupid and still survive.) Smart companies value their employees, are better able t
    • Or, just maybe, all of the "quit" responses were assuming the OP is rational enough to understand what it really means: start looking for a new job where you will be happier, and then quit.

      Obviously none of the posters here are seriously suggesting the OP just quit immediately over this issue.
    • That was the reasoning of all the Nazis "we had to support our families".

      A very drastic comparison, I know, but mate, there is just so much one can take and deal with. If there are, or were no consequences for bad behaviour, we would all be f.....

      I'm tired of sorry ass excuses. This is just one of them. Do you really think he will be able to support his family, once the company goes bust, and he's trying to get a new job? Does take your life into your hands mean anything to you?

      At least you got mod
    • > 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."

      You might not be aware that some people have very few expenses. If you're 21 and just out of college, you'll probably be living in a not-too-expensive apartment with a roommate. This makes rent like $300 a month, even in the city. Add in another $100 for utilities and $200 for foo
  • 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.

  • Joel! (Score:3, Interesting)

    by sootman ( 158191 ) on Wednesday December 28, 2005 @10:55PM (#14355733) Homepage Journal
    Great article on bug tracking here. [joelonsoftware.com] 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. [joelonsoftware.com]

    "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."

    • I'm gonna get troll-tagged into oblivion for this, but here goes nothing:

      Joel's argument is a platitude at best, and a fallacy at worst. He is plying his trade, no mistake about it: "Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time". Nonesense? Joel, buddy, casuistics ain't argument; what's good for you is... well, just good for you, not justification for anything. If you can't remember your name on odd days, it doesn't m

      • 100% agreed. If Joel (erm... "Mikey") had been non-braindead when programming, he would have used strncpy instead of "MikeyStrCpy". It's nice that you can track the bug, but it would be nicer to not make dumb mistakes :) :)

  • Quit but before that... (Score:4, Insightful)

    by GoofyBoy ( 44399 ) on Wednesday December 28, 2005 @11:10PM (#14355802) Journal
    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 "i accidently pushed my boss down the stairs" plan hasn't failed me yet.

  • BTDT (Score:1)

    by arb ( 452787 )
    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 s

  • as grace hopper said: (Score:3, Insightful)

    by blackcoot ( 124938 ) on Wednesday December 28, 2005 @11:17PM (#14355835)
    "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.

    • 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

      What exactly are you insured against?

      Just curious... I've never heard of any insurance against not having proper backups, and I'm not sure if it would be very expensive (since anyone who would need it is obviously not maintaining their backups), or very cheap (since anyone who would thin

  • 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.

  • Do it anyway (Score:4, Insightful)

    by Bastian ( 66383 ) on Wednesday December 28, 2005 @11:22PM (#14355855)
    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.
  • Short and sweet: If in Windows, use Excel for bug tracking. It's quick and easy, no installation required (except for the app), features can be added if needed, and nobody has to know about it.

    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.

    • One step up from using Excel as a bug tracker is to use Mantis [mantisbt.org] which is simple to use and written in PHP.

      Subversion or CVS as version control is about the same when it comes to a small project. Subversion is the successor to CVS and should normally be the choice unless there are other factors that makes it hard to implement.

      Obviously - the boss in question is probably also rejecting ISO 9000. And I even wonder about what the accounting looks like. So it may be a good idea to silently look for another jo

      • 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
      • has (ir)rational purify gotten any easier to use? i showed my boss valgrind (http://valgrind.org/ [valgrind.org]) and he couldn't believe how (relatively) painless it was to use. well, painless in terms of actually using, not painless in terms of how bloody slow things run (but that's kinda to be expected since they're emulating the machine...)

        i've reached a point where i run whatever project i'm working on through valgrind at least once every two weeks and usually more often than that (before every non-trivial commit). i
      • "Each method/function shall have a comment describing that comment."

        // tells the reader that this is where the program starts
        /*
          * the entry point of the application
          */
        main () {
            doThings();
        }
  • Ok so the "your boss is an idiot" comments have been covered. Cool. ;) I doubt this will help in such a small and culturally insular company, but I'll throw in my two cents that I've learned from Slashdot.

    If you have an objection to managerial policy, document the situation and your objection with Human Resources. Take the advice everyone else given here regarding the estimation of time/money lost and of unaccountability and unprofessionalism, make your presentation, and file it with H.R. Then see if

  • Take Matters Into Your Own Hands (Score:4, Interesting)

    by DJenk47 ( 212581 ) on Thursday December 29, 2005 @12:04AM (#14356047) Homepage
    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.
    • my superiors wouldn't allow any sort of bugtracking or versioning software

      Gah. A version control system, even if it is a weenie one like MS VSS, is one of the basic things separates amateur coding for fun from professional software development.

      "Source control is like flossing - you don't have to floss *all* your teeth - just the ones you want to keep." - Dave Scofield, Borland

      I had to write my own system

      You shouldn't need to write anything - you just need to get the hardware and time to install subversion [tigris.org]
      • You shouldn't need to write anything - you just need to get the hardware and time to install subversion and bugzilla
        Oh, I agree, both packages are superb. I used cvs for versioning and my little homebrew for bug-tracking. It was a rather pathetic system - no multi-user support, limited assignment ability, no reporting, - but it worked for me to be able to record what I needed to know so I could work. It was more for my own personal use to keep track of things than for any sort of professional wide-sprea
    1. set up subversion
    2. check projects in/out
    3. don't keep stuff on a public share


    when you boss asks where a particular project is, tell him "in the version control system". make life easy -> http://tortoisesvn.tigris.org/ [tigris.org]

  • Reiteration of comments (Score:3, Interesting)

    by Kalzus ( 86795 ) on Thursday December 29, 2005 @01:11AM (#14356353)
    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.
  • 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.
  • 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.
  • 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 f
  • 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 bug

  • Not a technical problem (Score:2, Insightful)

    by 4way ( 519502 )
    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 witho
  • 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:

    http://www.joelonsoftware.com/articles/fog00000000 43.html [joelonsoftware.com]

    If that doesn't work, I would recommend reading his article 'getting things done when you're only a grunt' - basically, it says that you should just go ahead and set these things up for your own use, and then maybe even get oth

  • How to sell to PHBs (Score:3, Informative)

    by MadFarmAnimalz ( 460972 ) on Thursday December 29, 2005 @08:07AM (#14357456) Homepage
    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.
  • 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 p
    • Amen. Too bad my last mod points just expired...
    • I think you've overlooked a very important line in the story:
      ...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)...
      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

  • 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 real
  • 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 p
  • 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.
  • 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.
  • 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.
    • >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.

      I'd think getting fired would be his loss as well.
      • His boss is setting him up for a fall. He can walk away, or not. If he chooses to stay (for reasons known only to him), then he can risk paying the price now, for doing the right thing, or pay a bigger price later, for keeping his mouth shut.

        Seriously, would you want to be known as a toady for this guy's boss?
  • 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 th

  • I started a new job this summer. First shock was to discover that bug tracking was handled with assorted spreadsheets all subtly different and a sprinkle of randomly formatted mail. Just reporting bugs and worse, gathering information about them was driving everyone crazy. I promptly took the initiative to write requirements and implement them by installing and parametering Mantis [mantisbt.org]. With barely a hint of evangelism it took on like bush fire. Userbase is now sixty users and growing. Bug tracking is back to s

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close