I hate my job...'s software.



  • *siiiiigh*

    Yes. I haven't worked here all that long... like three-five months, I forget. Not the point anyway.

    I would like to apply liberal quantities of bullets to whoever decided on our software.

    We use:

    • Visual Basic 6.0
    • Sourcesafe
    • SQL Server

    Now granted, these products could each and all of them be possible to configure to excellence... but I wouldn't know. I'd never touched any of them prior to working here.

    Why we're using VB6.0? Couldn't tell you. Apparently they chose it 10 years ago, and they still think it's easy to phase coders into the project because of it. Now I dunno... I coded some VB way back in school, and thanked all powers that be when we moved on to some actual object oriented languages later... granted I'm really BAD at C++, but I fancy myself at least mildly competent at Java, and it seems C# should be a cinch from that platform. VB is NOT an object-oriented language, no matter how much wishful thinking is employed by Microsoft to make it one. It lacks EVERY useful feature I could possibly ever want, the scope is horrid, the syntax is weird and... argh. I hate it ever so much. Give me something with proper event handling and object orientation, PLEASE?

    Then comes Sourcesafe. This one I'm not sure about. Is it actually this bad, or is it simply set up in a bad way? Back in my CVS days we could MERGE changes and whatnot... I'm writing this while waiting for a reply from the guy who's checked out the project file I should be working on, asking if he could check in the file for a moment so I can add a new class to the project... 'cuz Visual Studio is blankly refusing to accept that I add something to the project without OWNING it first. I dunno... if it actually works like this, why does anyone in the world use it?

    SQL server. I haven't really found anything fundamentally WRONG with this one, beyond the fact that our company sells a program that should be roughly 10mb, at a stretch, in a many-hundred-mb install package that includes a full SQL server install that the customer has to pay extra for... in order to maintain, at a guess, an average of 3-4 databases, going as high as possibly a thousand? The DB format is a WTF in and of itself, but I can't submit it as such because I weep whenever I try to put it into words. Regardless, there's nothing in there that requires software-specific features, garden variety SQL should be enough, so... for most clients SQLlite or something similar should do the job admirably, and for the few large clients an integration of some kind towards... well... ANY random SQL-compatible database should really do the job. Hell, even MS Access should be fine for most clients.

    So as I waste hours of waiting for the guy who has my project files checked out to get back to his desk (with my luck he's in sales and out travelling today), my will to live is slipping another notch down. Will anyone join me for some booze after work today?


  • :belt_onion:

    @WitherVoice said:

    So as I waste hours of waiting for the guy who has my project files checked out to get back to his desk
     

    Hijack the file, get on with your coding and WinMerge the changes back in once the other guy has released your file?

    http://www.winmerge.org/



  • As far as VB 6, it shouldn't even be used in new projects and you should be actively migrating to .Net or C++ if you want to stay with MS.  The development software isn't even on extended support anymore and the runtime is either close to or beyond EOL.  Using VB 6 is a tremendous risk.

    If you're using SourceSafe 6.0d, then yeah it sucks.  SS 2005 is much better and you can set it up to allow the Copy-Merge model allowing multiple people to edit the same file at the same time.  I haven't had any issues with SS 2005. 

    For SQL Server, if your installs are that small then SS Express might be an option.  It is free but has some limitations such as a 4Gb database max size and no job scheduling features.  Personally I prefer either Oracle or MS SQL from a developer perspective.

     



  • @WitherVoice said:

    • Visual Basic 6.0

     Anything bad that can be said about VB has been said 1000 times by now. As far as OO is concerned, I'm not aware that Microsoft calls it an OO language (it has some OO features, though, but it's classified as event-driven). The only VB "variant" that's OO is VB.NET, but that barely qualifies as a variant in the first place.

    While it's okay to still maintain a couple of legacy apps, migration to a different language (ANY other langauge) should have started about 4 years ago.

    @WitherVoice said:

    • Sourcesafe

    From what I've heard, it really is bad (but not necessarily *that* bad). VSS2005 is supposed to be vastly better than its predecessors (but I get the feeling that's not the one you're using). However, Microsoft have more or less discontinued SourceSafe in favor of their new Visual Studio Team Foundation Server (and personally, I'd go with SVN any day of the week), so that should give you an idea of how bad it is.

    @WitherVoice said:

    • SQL Server

    Nothing really wrong with it, even if other database systems could likely do it just as well. Sure, it adds quite a bit to the install package, but you can actually get pretty far with the free SQL Server Express (up to 4GB data), and Management Studio is a pretty nice app.



  • Indeed, bashing VB is not in and of itself a novelty. And yes, I have, upon starting work here, told them that using archaic software to keep developing our application is a f... umm... very stupid idea, and that migration should INDEED have commenced four years ago. I'd hardly be doing my JOB if I didn't remind them of this; now, however, it's out of my hands, yet every day feels like a tiny sliver of my soul is ripped off and violently crushed.

    I don't even know WHY we're still on an old version of Sourcesafe. And no matter how much it is improved, why would anyone anywhere in the universe NOT go with SVN (or CVS, if you're afraid of things that are... newer than bronze tools)? I don't get it.

    As for SQL Server... it's eating our profits, and that's the ONLY real effect it has. There's nothing really wrong with it, I agree, but come ON. Granted, over the years, I expect a database could get quite huge, a select few might even pass the 4gb point and need a "proper" database. And yea, I've said quite a few things about this whole thing, too. The answer is something akin to "yes, we have plans in place for migration to new development tools and platforms". From what I've been able to gather, those plans are just about thus: "two or three months before Visual Basic 6.0 irreversably stops working on a normal Windows platform, we will start reimplementing our program". How they are supposed to precognitively know this, I do not know.

    I'm guessing that at least a few of those who read this are inclined to answer something along the lines of "polish up your resume" or something like that. The sad fact is, this won't happen. We deliver a niche product to the most conservative niche on the face of the earth (accountants). Those who have chosen our product (which isn't actually inferior to the competition despite of all this, another fact that makes my stomach churn) will start to consider a change to a competitor's product ROUGHLY when it makes bees fly out of their monitor to sting their eyeballs. So in spite of itself, this company seems set for a long life. Sad, because I'd almost LIKE it to fail so that the frayed remains of a soul I have can soar on to greener pastures... sadly, I expect once I get there I will discover that they are green due to the cowdung that I just stepped in.

    Today is a wonderful day for pessimism.



  • @WitherVoice said:

    Then comes Sourcesafe. This one I'm not sure about. Is it actually this bad, or is it simply set up in a bad way?

    It's not that bad.  It's much, much worse, whole orders of magnitude worse than just "bad".  It might be set up badly in your case but I'm not sure there is a way to set it up well since the repository is just a bunch of cryptically named files in a shared directory.  I'm lobbying to get us to switch to Subversion but some people seem to actually like the "exclusive checkout" way of working.



  • @upsidedowncreature said:

    It's not that bad.  It's much, much worse, whole orders of magnitude worse than just "bad".  It might be set up badly in your case but I'm not sure there is a way to set it up well since the repository is just a bunch of cryptically named files in a shared directory.  I'm lobbying to get us to switch to Subversion but some people seem to actually like the "exclusive checkout" way of working.

    It wouldn't happen to do full-file backups too? Or does it actually use diff patches in any way?



  • @WitherVoice said:

    Then comes Sourcesafe. This one I'm not sure about. Is it actually this bad, or is it simply set up in a bad way? Back in my CVS days we could MERGE changes and whatnot... I'm writing this while waiting for a reply from the guy who's checked out the project file I should be working on, asking if he could check in the file for a moment so I can add a new class to the project... 'cuz Visual Studio is blankly refusing to accept that I add something to the project without OWNING it first. I dunno... if it actually works like this, why does anyone in the world use it?


    I'll leave the VB6 and MS-SQL comments up to other people even though I do use them myself.


    But I find the whole CVS vs VSS style of checkout an interesting issue (almost in an emacs vs vi class - except that VSS does have major architectural issues IMHO).

    VSS was the first source code management system that I ever used, and when I first started using a CVS style product I was horrified - you mean that if I am editing a file then someone could come along and edit the same thing at the same time and when we both did commits then we would manually have to merge everything all over again!?!?!?!

    From my point of view having VSS lock out the entire file blocks a whole category of issues that arise when you have to manually merge in code a la CVS. After all you may have spent all that time perfecting your code, getting it past the test harness and then bam you have to start all over again. However I have also been in the situation where I have been locked out of doing work because someone hasn't checked a file in - so in that situation CVS' style is better - but in the projects I worked on with a team of about 10-12 that was a rare occasion over a large code base. Personally I think of code in terms of files rather than lines, and that means I feel happier with the VSS model (However VSS itself is another issue)

    One situation where the VSS style is better is with binary files in the repository - you definitely do not want to merge one binary file with another!

    Finally if you think VSS is bad - I work with a 3rd party product that is layered over the top of VSS!



  • @WitherVoice said:

    It wouldn't happen to do full-file backups too? Or does it actually use diff patches in any way?

    I don't think it maintains a full copy of each version of each file, and it is possible to compare versions so there must be some sort of diff analysis.  Is this what you mean?



  • @OzPeter said:

    But I find the whole CVS vs VSS style of checkout an interesting issue (almost in an emacs vs vi class - except that VSS does have major architectural issues IMHO).

    VSS was the first source code management system that I ever used, and when I first started using a CVS style product I was horrified - you mean that if I am editing a file then someone could come along and edit the same thing at the same time and when we both did commits then we would manually have to merge everything all over again!?!?!?!

    From my point of view having VSS lock out the entire file blocks a whole category of issues that arise when you have to manually merge in code a la CVS. After all you may have spent all that time perfecting your code, getting it past the test harness and then *bam* you have to start all over again. However I have also been in the situation where I have been locked out of doing work because someone hasn't checked a file in - so in that situation CVS' style is better - but in the projects I worked on with a team of about 10-12 that was a rare occasion over a large code base. Personally I think of code in terms of files rather than lines, and that means I feel happier with the VSS model (However VSS itself is another issue)

    Fair points, I work in a team of about the same size so the exclusive checkouts aren't an everyday problem (until a dev machine's disk crashes, the developer goes on holiday etc).  The problems I have with VSS are, as you say, probably architectural and implementational (hey I invented a new word). 

    Architectural because of the previously mentioned bunch of cryptically named directories/files which comprise the repository, the fact their names don't bear any relation to the names of files in the project, the directory structure doesn't reflect that of the project, and the whole mess has to be accessible via SMB.  Also the fact that it's very susceptible to corruption and we've recently started experiencing files going missing, resulting in me being unable to check out some modules.  Admittedly we're using VS6, not 2005.  As well as Subversion I'm also going to take a look at MS Team Foundation Server, anyone got any experience on that?

    @OzPeter said:

    Finally if you think VSS is bad - I work with a 3rd party product that is layered over the *top* of VSS!

    *shudder*



  • @WitherVoice said:

    So as I waste hours of waiting for the guy who has my project files checked out to get back to his desk (with my luck he's in sales and out travelling today), my will to live is slipping another notch down.
    Out of curiocity why does someone in sales have a source file checked out?



  • That is an excellent question, and today, some days later, I still cannot answer it.



  • @WitherVoice said:

    That is an excellent question, and today, some days later, I still cannot answer it.

    Why would someone in sales even have access to version control? 



  • @morbiuswilters said:

    Why would someone in sales even have access to version control?

    Although I think your real question is "Why would someone in sales even have access to the development code version control?", version control systems are really good at .. you know .. version control. So they are useful for keeping previous versions of all sorts of things. For example: quotes, contracts, sales orders.



  • @OzPeter said:

    @morbiuswilters said:
    Why would someone in sales even have access to version control?
    Although I think your real question is "Why would someone in sales even have access to the development code version control?", version control systems are really good at .. you know .. version control. So they are useful for keeping previous versions of all sorts of things. For example: quotes, contracts, sales orders.

    Yeah, that was the implied question.  I've never seen non-developers use version control, though.  At least, not source version control.  They may use some kind of "document management groupware" thingy.  Hell, most sysadmins I've known won't go near CVS or SVN. 



  • Right.

    Upon asking around a bit I find that the person in question writes customizations for "quality-conscious customers with special requirements", that is, people who bother support and have the money to pay for making their specific problems go away, then tries to "sell" MORE such solutions to the customers in question, under the assumption that if they were prepared to pay once, they might be again.

    This IS, I will freely admit, my misantropic, pessimistic translation of the information I was presented with.

    Looking at some code he's produced, he's actually pretty competent... compared to some of the people who have written code in this project. It's fairly legible and structured, and there are comments.



  • @morbiuswilters said:

    I've never seen non-developers use version control, though.  At least, not source version control.  They may use some kind of "document management groupware" thingy.  Hell, most sysadmins I've known won't go near CVS or SVN.

    I have worked in (albeit engineering) companies where all documentation and quotes etc was keep under source control. And as such even the office manager who did no technical work had to know how to get stuff in and out of it, and could recover previous versions etc.

    On the other hand I have worked for other companies where there was no source/document control at all. And you end up with lots of files with names like "file_001.doc" or "file_previous.xls" scattered all over the place. Source control is great for all sorts of items other than source code.

    One thing that I find sad is that VMS had built in file versioning and since then we have gone backwards.



  • @OzPeter said:

    @morbiuswilters said:
    I've never seen non-developers use version control, though.  At least, not source version control.  They may use some kind of "document management groupware" thingy.  Hell, most sysadmins I've known won't go near CVS or SVN.
    I have worked in (albeit engineering) companies where all documentation and quotes etc was keep under source control. And as such even the office manager who did no technical work had to know how to get stuff in and out of it, and could recover previous versions etc.

    On the other hand I have worked for other companies where there was no source/document control at all. And you end up with lots of files with names like "file_001.doc" or "file_previous.xls" scattered all over the place. Source control is great for all sorts of items other than source code.

    One thing that I find sad is that VMS had built in file versioning and since then we have gone backwards.

    I've worked with and without source control, too.  And I totally agree that it is fantastic and I store every damn thing I do in SVN.  However, I've never seen anyone other than developers use a version control system.  Like I said, even the sysadmins I've worked with will not go near it for storing config files, docs, etc.. 



  • @morbiuswilters said:

    Like I said, even the sysadmins I've worked with will not go near it for storing config files, docs, etc..

    Maybe you are trying to sell them the wrong system. Perhaps a more robust and user friendly system would be better .. like .. VSS


    ducks



  • I was stuck with using VSS during my last job.  The "rule" was that only one developer could have a file checked out at any given time.  We also had a "shared" development environment, so all the files in "development" were the same for every developer.  This seemed inherently stupid to me (even though this was my first experience with any source control system), but it was rare for this to be an issue because we had such a small team (only 4 developers), and we rarely worked on the same files at the same time.  It lead to me getting in the habit of keeping files checked out until they were pushed to production.  That seemed like the only logical solution for such an insane system.  However, it still presented problems when someone needed to work on a file I had checked out.  And when that problem reared its ugly head, the shit hit the fan...

    I went on vacation for a week and left a bunch of files checked out because I was still working on them.  Mid-way through the week, a co-worker sent me an e-mail that indicated he needed to work on one of the files I had checked out.  He also added, "you need to check in all of your files when you go out of town so other people can work on them."  I tried to explain why this presented a bigger problem, because he could easily push up my changes to production before they were ready to be pushed.  If the files weren't checked out, he would have no idea of knowing if they were still being worked on.  I went on to explain why we needed to re-thinking our source control/development system.  He didn't really present a solution for the problem, but said, "I understand where you're coming from, but this causes major problems when people are out for a long period of time.  You need to check in your files before leaving."

    At that point, I just gave up...The rest of that job was fine (even enjoyable most of the time), but we had long since outgrown the source control system and a lot of the developers were needlessly against changing it.

    My new job is completely different.  Every developer workstation has its own "development enviornment" and we use a souce control system that actually supports crazy new concepts like "merging".  I don't even know why VSS is used by anyone.  It keeps track of file changes and that's about it.



  • @bighusker said:

    I went on vacation for a week and left a bunch of files checked out because I was still working on them.  Mid-way through the week, a co-worker sent me an e-mail that indicated he needed to work on one of the files I had checked out.  He also added, "you need to check in all of your files when you go out of town so other people can work on them."  I tried to explain why this presented a bigger problem, because he could easily push up my changes to production before they were ready to be pushed.  If the files weren't checked out, he would have no idea of knowing if they were still being worked on.  I went on to explain why we needed to re-thinking our source control/development system.  He didn't really present a solution for the problem, but said, "I understand where you're coming from, but this causes major problems when people are out for a long period of time.  You need to check in your files before leaving."

    Thanks, good post, do you mind if I use this in evidence against VSS?   Pfft, I'm going to anyway...



  • @WitherVoice said:

    • Visual Basic 6.0
    Oh no. Please no. Fortunately the last time I was punished with this was during college, and only in one course.@WitherVoice said:
    • Sourcesafe

    I only used this once, for a college project where our college was trying to push for MCSE's. Our project was done in Visual C++ 6.0, no problems there; though we ended up using Qt, as we had more experience with that than with MFC (which only the professor knew.) However, we were slapped with Visual SourceSafe. This thing made me cringe, and hell, I was using command-line CVS back then! (Ok, I switched to the Cervisia front-end during the semester, but you get my idea.)

    The damned thing was a nightmare for merging more than one file with the HEAD branch. It just couldn't be done in bulk, we had to point-rightclick-merge every damned file ... which meant about 30+ clicks when the thing got big enough. As a plus, even with the checkin/checkout, some of our teammates were able to break stuff; the main VC++ project was broken at least 5 times.

    Most of our teammates were not even using the thing by the end of the semester, only checking in when they did major changes (they did all modifications in another VSS-free folder) and generally screwing up the code when they did so. I actually fired up my own CVS repository, which some of us used in parallel with the VSS one, and also to have a good backup just in case someone else ruined the VSS one.

    The next semester, that teacher decided to drop the MCSE stuff and switched the course to Java, using CVS. None of us have ever touched VSS again.



  • I use the same set of tools, and they work quite well for me.  I am the only developer so the issues with Source Safe you mention do not affect me.  When I started work on 11 years ago, I used VB which was state-of-the-art and especially good for data entry screens.  When VB.Net came out, I installed it and messed around with it for a while, and while I had nothing against it, I could see no reason to migrate to it.  It would have taken a year to migrate and no client would pay for our time to do so.  There has never been any programing problem I have come across that could not be solved in VB.  Maybe using C# or Java makes you feel like more of a programmer but I doubt it makes you any more productive than I am in VB6.  There are over a million VB applications out there, so IMO it would be a monumnetal mistake for Microsoft to come out with a version of Windows that is not compatible in the next 30 years or so.  As for MS SQL, all of our clients already were using it anyways, and we haven't come across many issues with it that were not caused by user-error.  I agree that for a new project VB6 makes no sense, but if you have a functioning application of any size (we have a few hundred thousand lines of code) that only needs occasional revision, it makes even less sense to do a rewrite.

     



  • VSS's help file reveals an alleged ability to merge, but I cannot find anything to perform a merge in the interface. Checkin just adds another history item. Where is this mythical "merge" people speak of?



  • Depends on the type of merge.  If it is as simple as two people editing the same file, just check in and if a conflict occurs; you'll get a merge dialog if conflicts are detected.  Essentially, check-in equals merge when using the Get Copy/Merge model.  If it is a branch and merge, than you get a Merge Branches context menu for unpinned items between the branches.  You'll occasionally get a merge conflict dialog when getting latest as well.  So at least in my experience with VSS, merging is done mostly automatically without any explicit user interaction.





  • @Salami said:

    I use the same set of tools, and they work quite well for me.  I am the only developer so the issues with Source Safe you mention do not affect me.

    The reason you haven't had any issues with VSS is because you are the only developer. It is when you have more than one dev that VSS' quirks start surfacing. In my experience, the worst thing I ever had to deal with was the "Merge Branches" operation, as it had to be done file by file!


  •  My sympathy on the VB and SS. I have no problem with SQL Server personally.


Log in to reply