• fuffuf (unregistered) in reply to DOA

    Sure, he just shrugs at Merv, as he's obviously not to blame for what went wrong. A good manager would hide his anger and possible other emotions from the employees that don't have anything to do with it, as evaluating Joe's performance is a personal affair.

    Even being emotional towards Joe would probably not be very effective. Just make a decision and take action. Be clear about your motivation and your expectations, help the employee to do better and give people a chance to learn and better their ways. If that doesn't help, it's time to go talk to HR.

  • (cs) in reply to The real wtf fool
    The real wtf fool:

    How I see the situation: They are developing a web app in php or similar and have just one dev web server with php installed. So everyone does their development on the files in the dev server. Joe is editing some php files on the dev server, has all his changes done. Merv checks a file out from source control to the dev server, thus overwriting the file that Joe has edited. So all Joe's changes are overwritten. The only thing that doesn't support this hypothesis is that the checkout did not warn on seeing the file was different to the version in the repository, but maybe some SCCS behave like this?

    They can be forced to. The logic would go that the dev environment should always be the latest in the repo so they can be properly tested and since nothing on the dev server should ever be edited we want to just overwrite so we have a clean environment.

    I some cases I've seen that done intentinally as a LART.

  • (cs) in reply to Joon
    Joon:
    Joe:
    I'm looking into how to keep the most up to date version of the repository out in a live environment,

    ...

    Joe, is that you? hehe, just kidding.

    Typically people use seperate tools for deploying vs source control.

    ...

    Another newb here:

    I must confess the idea of a 'build server' or an 'integration server' is not clear to me, having never worked in a firm that utilized these (I set up version control in my present firm).

    How relevant are these for non-.Net platforms, like PHP, for example? Also, where would be a good place to learn about best practices for deployment/development? Please don't suggest "a Bachelors degree in IT/Comp. Sci", or "Google". My BSc in IT degree taught nothing relevant, and Googling is what I'm about to do - pointers would just be welcome. :)

  • Mike (unregistered) in reply to donniel
    donniel:

    Another newb here:

    I must confess the idea of a 'build server' or an 'integration server' is not clear to me, having never worked in a firm that utilized these (I set up version control in my present firm).

    How relevant are these for non-.Net platforms, like PHP, for example? Also, where would be a good place to learn about best practices for deployment/development? Please don't suggest "a Bachelors degree in IT/Comp. Sci", or "Google". My BSc in IT degree taught nothing relevant, and Googling is what I'm about to do - pointers would just be welcome. :)

    In the places I have worked : Build server. A place the application is built that is not a developers local machine. Used to check we have all the dependencies documented and we can build from source control. Stops the problem of builds working on a developers machine and not in production if a resource has not been checked in. Best to have something like cruise control doing regular builds to it so problems appear as soon after a commit as possible.

    Integration server. As close to the production environment as possible with real data / TIBCO layers what ever is appropriate rather than a local stubbed set up for testing. Usually appropriate if you are dealing with complex 3rd party systems.

  • (cs) in reply to donniel
    donniel:
    How relevant are these for non-.Net platforms, like PHP, for example? Also, where would be a good place to learn about best practices for deployment/development? Please don't suggest "a Bachelors degree in IT/Comp. Sci", or "Google". My BSc in IT degree taught nothing relevant, and Googling is what I'm about to do - pointers would just be welcome. :)

    Imagine having a test web server to check and see how it all looks and works before going live.

  • Doesn't matter (unregistered) in reply to donniel
    donniel:
    Joon:
    Joe:
    I'm looking into how to keep the most up to date version of the repository out in a live environment,

    ...

    Joe, is that you? hehe, just kidding.

    Typically people use seperate tools for deploying vs source control.

    ...

    Another newb here:

    I must confess the idea of a 'build server' or an 'integration server' is not clear to me, having never worked in a firm that utilized these (I set up version control in my present firm).

    How relevant are these for non-.Net platforms, like PHP, for example? Also, where would be a good place to learn about best practices for deployment/development? Please don't suggest "a Bachelors degree in IT/Comp. Sci", or "Google". My BSc in IT degree taught nothing relevant, and Googling is what I'm about to do - pointers would just be welcome. :)

    You want a pointer? How about 0x1A66BFD4 ?

  • AlanGriffiths (unregistered) in reply to real_aardvark
    real_aardvark:
    AlanGriffiths:
    But even if you are using something as uninformative as you imply it is easy to script a solution: delete the target directory tree before exporting files to the production server.
    That's some seriously bad advice right there. I'd go so far as to say that it's a worse "solution" that having no source control at all and simply editing files on the production server.

    (1) If at all possible (and the only constraints are disk space and installation time) take a back-up of all important files before every installation. Otherwise roll-back is ahem problematic.

    Where did I say "don't take a backup"? You didn't mention testing the update on an off-line server before putting it live either, but this too is normal practice and I don't assume you're advising against it.

    In the part of my post that you cut I said that IF (and you and I agree that that is a very big "if") one is otherwise satisfied that source control can deliver files into a production environment then...

  • synp (unregistered) in reply to fuffuf

    There were Joes like that in every place that I worked.

    Any long-lived project has nearly all the developers working on a rather small portion of the code. Much of the code is old, and has hardly been touched for several years. With the high churn of developers, you've got lots of code that nobody's looked at since before most of the devs in the company came aboard.

    That's where the Joes come in. They've been there since forever, so they've seen all these obscure pieces of code. If something needs updating in one of those places, they can hit the ground running. Another dev would take days to get to know the old code and figure out how it works. That's what makes the Joes of the world valuable to the companies and their managers. Ideally, these Joes also train the newcomers, but I can't see this particular Joe doing it.

    Hey, I've been with my company for almost 8 years. I'm a Joe!

  • (cs) in reply to The real wtf fool
    The real wtf fool:
    JimM:
    Actually, there is one and only one reason I've never used formal source control in my work. I've never worked in a team larger than.. well... 1.
    Still no excuse!
    I beg to differ - it's definitely an excuse - it's just not necessarily a good one (and probably therefore not a "reason" as such)! Seriously though, most of my code changes tend to be to fix bugs rather than add features, and because of the scale of the projects most of those are typos rather than algorythmic or architectural problems, so having the old code available isn't really much of an issue. At that point Source Control is a nice-to-have rather than a must-have.
    The real wtf fool:
    It's not that hard to get up to speed. ... Then you can add it to your resumé.
    On this you're almost certainly right. Unfortunately I've yet to be in a position where I have time to break from either fire-fighting other people's bad code or doing last minute rush job implementations because the previous developer left before writing anything. On the other hand it looks like my current project might settle into routine maintenance in a few weeks and I'm, not expecting anything else to come up over summer, so I might actually be in a position to look at some of your recommednations!
  • Kuba (unregistered) in reply to JimM
    JimM:
    Sanity:
    So if your name is not Linus Torvalds, there really is no excuse...
    Changes name by deedpoll ;^)

    Actually, there is one and only one reason I've never used formal source control in my work. I've never worked in a team larger than.. well... 1. I occasionally worry that my lack of source control knowledge will be a barrier to getting a job on a larger dev team in the future; but then I come and read TDWTF and realise that I'm probably not so badly off after all ;^)

    I was on a one-man team for quite a while, and I've used source control since day one. If for nothing else, it lets you try different approaches (branches) without breaking shipping version, and lets you document the work done.

  • (cs) in reply to Doesn't matter
    Doesn't matter:

    ...

    You want a pointer? How about 0x1A66BFD4 ?

    I actually wondered if somebody would make this joke :)

  • The real wtf fool (unregistered) in reply to donniel
    donniel:
    Doesn't matter:

    ...

    You want a pointer? How about 0x1A66BFD4 ?

    I actually wondered if somebody would make this joke :)

    should have given him 0xBAADF00D

  • Art (unregistered) in reply to Satanicpuppy

    Until a few months ago, I worked with a "developer" who regularly edited live code. She wasn't very keen on testing either, so mistakes were found by other team members or clients. It was an absolutely nerve-wracking way to work.

  • (cs) in reply to Gerhard
    Gerhard:
    donniel:
    How relevant are these for non-.Net platforms, like PHP, for example? Also, where would be a good place to learn about best practices for deployment/development? Please don't suggest "a Bachelors degree in IT/Comp. Sci", or "Google". My BSc in IT degree taught nothing relevant, and Googling is what I'm about to do - pointers would just be welcome. :)

    Imagine having a test web server to check and see how it all looks and works before going live.

    Yes, a test or staging server is something I always use - is that the same as a build/integration server? The usual sequence is Development/Test/Production.

    All the projects I've worked on were simple enough to work well without requiring a build server. But I see the value of it, and will definitely learn more about it, and start integrating it into my process.

    I remember the time (a few years ago), when I first tried to start with a revision control system (SVN) - before that I had been using automated backups. There was a period when the whole exercise of version control seemed pointless and convuluted. Now, I wouldn't get out of bed without doing a commit!

    P.S. Speaking of which, the latest version of TortoiseSVN seems to have a few bugs. Hmm...

  • Richard (unregistered) in reply to The real wtf fool
    Doesn't matter:
    should have given him 0xBAADF00D
    I always preferred 0xDEADBEEF... may be showing my age a little.
  • Richard (unregistered) in reply to The real wtf fool
    Doesn't matter:
    should have given him 0xBAADF00D
    I always preferred 0xDEADBEEF... may be showing my age a little.
  • (cs) in reply to Dave
    Dave:
    cant you check out previous versions in most if not all source control systems?

    Only if they were checked in in the first place.

    Since Joe didn't use source control, there was no previous version checked in with the changes he'd spent two weeks making.

  • Richard (unregistered)

    And as far as backups go...

    I know that in my shop, we back up the SVN repositories daily. We back up a ton of stuff, actually. One of the few things that we absolutely do not back up is the automated extracted-source directory on our build server, which is where it seems that Joe was making his changes. So yeah, he probably lost two weeks of code.

  • Adam (unregistered) in reply to SoonerMatt
    SoonerMatt:
    Ha! Ha! Ha!

    I had this same thing happen at my workplace. The only difference was that I had been asked to restore a staging environment from svn. The month earlier I had migrated ALL code from VSS to SVN. This allowed all php code to be used by the linux developers too.

    A student dev had been dev'ing on our stage environment and was not using SVN as I had made available and recommended to our team ealier.

    So I overwrote weeks worth of work when I pushed the code to stage.

    The student had to explain to his boss why all of his work was gone, and I had to report to mine that I simply used our version control system.

    I don't see why teams will allow people to not use version control. It costs these teams TOO much money.

    Backing up before you click the button would have been the intelligent thing to do.

    When you've worked in the industry for a while you'll realise it's not so cut and dry and that some people need a little help.

    Relying on tools to do your thinking for you is a little naive.

  • Rance Mohanitz (unregistered) in reply to DOA
    DOA:
    So Joe is temperamental, abusive, his stupidity just costed the company a lot of man hours of work and his manager just shrugs? It's a cliche but I have to say it... that's TRWTF.

    "Costed" - now that's TRWTF!

  • Joe (unregistered) in reply to The real wtf fool
    The real wtf fool:
    donniel:
    Doesn't matter:

    ...

    You want a pointer? How about 0x1A66BFD4 ?

    I actually wondered if somebody would make this joke :)

    should have given him 0xBAADF00D

    Well now you're just sending him to memory his app doesn't have access to. Sneaky sneaky hacker...

  • oldbutnotwise (unregistered)

    In my last place of work i was introduced to svn (previously only used sourcesafe). The problem was it seemed to keep losing its history.

    one day it would have a history of the recent changes the next - nothing

    this became a big issue when i relised that not only was the history disapearing but so were changes that I and other developers were making, it got to a stage where I was going to bin svn and buy a copy of sourcesafe.

    Then an incident where one of the other developer was caught making obscene comments in his code (well we found the comment and svn tracked him as the source) well as soon as this was mentioned the history disapeared, sure enough the developer had a admin login and was deleting the svn directory and copying his local one in its place.

    seems that he had been doing this for a while to hide some right wtfs in his code.

    so even source control is not proof against dubious programers

    (needless to say he had the admin rights removed pdq)

  • (cs) in reply to Kuba
    Kuba:
    JimM:
    ... I've never worked in a team larger than.. well... 1.

    I was on a one-man team for quite a while ... it lets you try different approaches (branches) without breaking shipping version, and lets you document the work done.

    I pray for the day I have a job interesting enough to try different approaches on! Or indeed, something that needs "shipping". Pretty much everything I produce is internal, has one specific function, and was required yesterday. As I said before, Source Control is something I will look into when I am not actually writing code 7.5 hours a day...

  • (cs) in reply to JimM
    JimM:
    Kuba:
    JimM:
    ... I've never worked in a team larger than.. well... 1.

    I was on a one-man team for quite a while ... it lets you try different approaches (branches) without breaking shipping version, and lets you document the work done.

    I pray for the day I have a job interesting enough to try different approaches on! Or indeed, something that needs "shipping". Pretty much everything I produce is internal, has one specific function, and was required yesterday. As I said before, Source Control is something I will look into when I am not actually writing code 7.5 hours a day...
    (Quite serioiusly ...) Have you tried looking on Dice? Used to be an excellent filter for good-quality jobs when I was working in California between 1994 and 2000 (fell of the end of the visa, guv).

    There has to be something better than what you're doing right now.

    Meanwhile, look up the four minute Subversion course and practise. It'll put you in the top 20% of US programmers, as far as I can see.

    (ANd yes, it is useful for single-person projects. It's saved my ass a lot more times than I can tell you.)

  • zonk (unregistered) in reply to oldbutnotwise
    oldbutnotwise :
    Then an incident where one of the other developer was caught making obscene comments in his code (well we found the comment and svn tracked him as the source) well as soon as this was mentioned the history disapeared, sure enough the developer had a admin login and was deleting the svn directory and copying his local one in its place.

    seems that he had been doing this for a while to hide some right wtfs in his code.

    so even source control is not proof against dubious programers

    Poor IT practises are the problem here, not source code.

  • uncontrolled (unregistered)

    Sometimes, doing the other half of source control helps too. Like setting the privs on the live checked out files to be untouchable.

  • Joe (unregistered) in reply to JimM
    JimM:
    Kuba:
    JimM:
    ... I've never worked in a team larger than.. well... 1.

    I was on a one-man team for quite a while ... it lets you try different approaches (branches) without breaking shipping version, and lets you document the work done.

    I pray for the day I have a job interesting enough to try different approaches on! Or indeed, something that needs "shipping". Pretty much everything I produce is internal, has one specific function, and was required yesterday. As I said before, Source Control is something I will look into when I am not actually writing code 7.5 hours a day...

    Is there anything more boring than writing internal, business software?

    http://www.joelonsoftware.com/articles/FiveWorlds.html

    Internal software only has to work in one situation on one company's computers. This makes it a lot easier to develop. You can make lots of assumptions about the environment under which it will run. You can require a particular version of Internet Explorer, or Microsoft Office, or Windows. If you need a graph, let Excel build it for you; everybody in our department has Excel. (But try that with a shrinkwrap package and you eliminate half of your potential customers.)

    Here usability is a lower priority, because a limited number of people need to use the software, and they don't have any choice in the matter, and they will just have to deal with it. Speed of development is more important. Because the value of the development effort is spread over only one company, the amount of development resources that can be justified is significantly less. Microsoft can afford to spend $500,000,000 developing an operating system that's only worth about $80 to the average person. But when Detroit Edison develops an energy trading platform, that investment must make sense for a single company. To get a reasonable ROI you can't spend as much as you would on shrinkwrap. So sadly lots of internal software sucks pretty badly.

  • tom (unregistered)

    I can't image how this could even happen. At least with Subversion or CVS, it's impossible to edit source directly in the repository in a straightforward way. You have to check out a local copy to work on, so how can a commit damage something?

  • anon coward (unregistered)

    Alex,

    Where do you find these hilarious images??

    [image]

    I'm going to use the image from this article in all my new applications when there's an error!

    P.S. Long time reader, love the site; keep up the good work!

  • dm (unregistered) in reply to DOA
    DOA:
    So Joe is temperamental, abusive, his stupidity just costed the company a lot of man hours of work and his manager just shrugs?

    The manager probably knew they could get Joe's work back from a backup and has probably been waiting for an excuse to tell Joe to be a team player.

  • (cs) in reply to Richard
    Richard:
    Doesn't matter:
    should have given him 0xBAADF00D
    I always preferred 0xDEADBEEF... may be showing my age a little.

    The fingers start trembling and hit the button twice. It's sad to become old.

  • Brill Pappin (unregistered)

    I am always amazed at how many developers don't know how to use version control... it should be one of the first things they are taught in school or by peers.

    Now there is a WTF.

  • Dave (unregistered) in reply to Brill Pappin
    Brill Pappin:
    I am always amazed at how many developers *don't know how* to use version control... it should be one of the first things they are taught in school or by peers.

    Very true :( I think the Source Control HOWTO is a good resource for those who are new to source control:

    Our universities don't teach people how to do source control. Our employers don't teach people how to do source control. SCM tool vendors don't teach people how to do source control. We need some materials that explain how source control is done. My goal for this series of articles is to create a comprehensive guide to help meet this need.
  • (cs) in reply to real_aardvark
    real_aardvark:
    JimM:
    As I said before, Source Control is something I will look into when I am not actually writing code 7.5 hours a day...
    Have you tried looking on Dice? ... There has to be something better than what you're doing right now.

    Meanwhile, look up the four minute Subversion course and practise. It'll put you in the top 20% of US programmers, as far as I can see.

    That'd be really useful if I was a US programmer ;^) But I'll bear it in mind if I ever get the chance to move out to Pasadena...

    Joe:
    Is there anything more boring than writing internal, business software?
    Internal software only has to work in one situation on one company's computers ... Here usability is a lower priority ... So sadly lots of internal software sucks pretty badly
    There is little more boring than writing internal business software. I do want to take issue with Joel's article that you quoted, though. Usability is actually a higher priority for internal software (why? Because the users not only know who wrote the software, but also where to find them! Keep your users happy...), and the amount of resources committed - particularly employee time, which is expensive - is generally fairly high (particularly in relation to the complexity of the software, which is usually not that high). The real barrier to good quality internal software is that most companies don't have programmers on the staff to start with, and very few will look to employ programmers if software isn't their primary market. So the people who write internal software actually tend to be IT support / maintenance staff (I was a systems support officer when I wrote my first internal software, using (you guessed it) VBA / Access) who get sequestered off to a project team. Your team (if you get a team, rather than a sole "developer") will largely be self-taught, and you're unlikely to have anyone with the experience to architect a good solution. So you get pretty poor software.

    Of course, what these companies should be doing is looking for a small local software house and buying a proper, bespoke software development. Unfortunately, a lot of the small local software companies are a) cowboys, b) incompetent, or c) Magpies, and the software they produce is little better than the stuff churned out by the self-taught project team. In business, it really sucks to have unusual software requirements...

  • frijole (unregistered)

    as a cc admin, I'm not sure how the file is lost if there is a version control system..

    ~shrug~

  • schlub (unregistered)

    How is it possible to lose 2 weeks of work? At worst it should only be that days work since the overnight backups ran. That would the the WTF for me!

    I currently have 3 tiers of backups... one is a local copy on my own machine, two is a copy on the dev server which is backed up nightly, and thirdly all of that is going in and out of a source-control system which is also backed up nightly. Actually, we also have shadow-copying enabled on the servers so that would be a fourth copy.

    I come across this kind of half-arsed source-control use all the time, so before I push anything to the live server I do a file comparison. If I have hundreds of files to update then I will simply make a backup of the live version before doing anything.

    A few ex-employees used to make changes to the live DB's all the time without making any backups first... suffice to say they didn't last very long when they brought the client DB to a screeching halt for an entire day.

    I live by the phrases "If in doubt, back it up" and "back it up, just in case". This has saved my skin more times than I can remember.

  • Dodoh (unregistered)

    Ah! This is too cool. We the follow the same tradition here, at our company. Some groups have a zip file that needs to be extracted before build, so that the necessary files are overwritten appropriately.

    In one instance, a preprocessor was used to generate the source which generates the executables, and someone modified the source (not the code to be preprocessed). So, during the code review, I was matter-of-factly informed that I need to pull in their modifications (to the intermediate code). I have successfully passed on the tradition of source control control.

  • Spudd86 (unregistered) in reply to Sanity

    Linus used Patches and tarballs as a primitive source control system, because, for him, it was easier to merge everyone's changes that way, and if you look at how git works it is essentially the same work flow, just automated and full of awesome.

    I wouldn't want to use patches and tarballs, but I've never been trying to merge changes from thousands of developers.

    I can see why he didn't use CVS or SVN, they are incapable of supporting the development model that the kernel uses, a distributed version control system CAN, but for a long time there weren't any that were ready for production.

  • Spudd86 (unregistered) in reply to oldbutnotwise
    oldbutnotwise:
    In my last place of work i was introduced to svn (previously only used sourcesafe). The problem was it seemed to keep losing its history.

    one day it would have a history of the recent changes the next - nothing

    this became a big issue when i relised that not only was the history disapearing but so were changes that I and other developers were making, it got to a stage where I was going to bin svn and buy a copy of sourcesafe.

    Then an incident where one of the other developer was caught making obscene comments in his code (well we found the comment and svn tracked him as the source) well as soon as this was mentioned the history disapeared, sure enough the developer had a admin login and was deleting the svn directory and copying his local one in its place.

    seems that he had been doing this for a while to hide some right wtfs in his code.

    so even source control is not proof against dubious programers

    (needless to say he had the admin rights removed pdq)

    git would have prevented this, every commit has an SHA1 hash, and everyone has complete copy of the history, so it is only possible to change the history if you can break SHA1. Linus did it that way on purpose.

  • Spudd86 (unregistered) in reply to uncontrolled
    uncontrolled:
    Sometimes, doing the other half of source control helps too. Like setting the privs on the live checked out files to be untouchable.

    WRONG proper source control has no need for file locking.

  • Spudd86 (unregistered) in reply to tom
    tom:
    I can't image how this could even happen. At least with Subversion or CVS, it's impossible to edit source directly in the repository in a straightforward way. You *have* to check out a local copy to work on, so how can a commit damage something?

    WRONG you can edit a CVS repo directly, although it's a REALLY BAD IDEA, it can be done, if you know enough about CVS. The repo is human readable (after a fashion...)

  • Sir Geek (unregistered) in reply to DOA

    Why should the manager be mad ?

    "Joe" has already been warned. Perhaps this will be a way to get rid of Joe once and for and not be open to any law suits ?

    "I'm sorry, but Joe continuously fails to follow our departments procedures. So for this reason we have to let him go."

  • Steve (unregistered) in reply to blackd

    Does nobody take backups of development environments these days?

  • irving prime (unregistered)

    So in addition to not using source control this guy didn't ever back up his work?

    I don't understand how someone that stupid manages to be employed ... except possibly in management or politics.

  • DJ (unregistered) in reply to Ed Swangren
    Ed Swangren:
    DOA:
    So Joe is temperamental, abusive, his stupidity just costed the company a lot of man hours of work and his manager just shrugs? It's a cliche but I have to say it... that's TRWTF.

    The word "costed" is a WTF in and of itself.

    The meaning of "is."

Leave a comment on “Source Control Mastery”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article