Great Developers Use Source Control

  • Comments posted to this topic are about the item Great Developers Use Source Control

  • Saying using source control doesn't make you a better developer might be a bit conservative. Since it does enable you to quickly review your edits in a way that would otherwise be fairly impractical and thus take longer to do. So I think it's fair to claim that using source control makes you a slightly better developer, regardless of the other benefits mentioned.

  • I just sleep better with source control. I've only had a couple of instances in 20 years where the master copy of an application has become irreversibly mangled to the point where I could not seem to fix it that was two instances too many. Had source control so wasn't an issue.

  • The thing I like about Redgate Source Control is that it introduces a mechanism to put the data in smaller tables under source control as well.  This means that rebuilding a DB from source control gives both the structure and enough data for the dependent app to function.

    I've been writing a piece for Tony Davis about how I used the lessons learned from Redgate SSC and applied them to AWS RedShift and HP (now Microfocus) Vertica.  One possible improvement I have suggested is that Redgate add the ability to bcp or BULK INSERT source controlled data. At present the tool using multiple INSERT INTO statements.  Column store databases much prefer bulk loading rather than record by record entry and I think this would be relevant for SQL Server column store indexes as well.

    Source control gives so many advantages

    • The ability to rebuild different pre-production environments to different versions of the app and DB
    • Fine grained visibility of changes...don't underestimate the power of this one
    • The ability to branch/merge
    • With Git in particular the ability to allow development to continue when working disconnected (provided you have a local build of your DB)
    • Recording light weight decisions in MD (markdown) files within source control along with code means you maintain a record of WHY a particular approach was taken.

    • Installation and setup document in MD files (Github has an explicit wiki shadow project structure) so that documentation and code live side by side

    • Code commit insights.  How active is development?

    • Integration into other tools such as CI servers, task tracking software, messaging software, code analysis software

  • Having recently implemented Source Control for the first time, I have wondered why I never did it sooner.  I am using Visual Studio Team services and find it works well.  And has already had benefits and auditability within our team.

  • I use SVN for both .Net code and T/SQL stored procedures/functions.

    There have only been a couple of times when I had to revert to a previous version of a file, I find it most useful for reviewing when I have made large changes to a file and want to see where the changes are and what the code used to say, generally when I'm debugging something.

    Also got to say having a backup copy of *every* change to code gives me the warm and fuzzies. 🙂

    I'm a lone wolf developer so I can't speak to the team aspects of VCS (as I left a team environment before VCS was widespread), but I think I want to pick a nit about VCS making you naturally comment more. Commenting has always been something of a pet cause for me, my code is typically 70% comments and I can't proclaim their benefits loudly enough. But I've worked in team environments and can guarantee my view of comments is very rare. Most programmers disdain them--even in a peer reviewed work environment. I have to say I've never understood that!

    Comments are the life preserver when you're all alone in the middle of a storm tossed ocean!

  • The proper term for a developer who doesn't use source control is "amateur".

  • GeorgeCopeland - Thursday, March 15, 2018 7:21 AM

    The proper term for a developer who doesn't use source control is "amateur".

    WOW, I was an amateur for over 25 years.  Version control is very helpful, but I don't think it has any bearing on how good or great of a developer you are.  In my prior job I consider the developers i worked with to be great developers, and we did not have version control.  In my current job almost everything is version controlled.  Would I consider all of those developers great?  No I wouldn't.  I do think version control sometimes is used as a crutch for bad coding(developers).  IMHO

    -------------------------------------------------------------
    we travel not to escape life but for life not to escape us
    Don't fear failure, fear regret.

  • I am a firm believer in source control. When I came to this job I became an adamant believer in source control. One of the first assignments I was given was to update an ASP.NET web app. I think I had about 6 weeks in which to get it done. The problem was the original developer had some very odd views about his code. He didn't bother to use source control for anything. And when he left he told the Operations dept. to flatten his machine, which they did. But his machine was the only machine with the source code for the ASP.NET app. Consequently, there wasn't any source code available for me to work with. Fortunately Operations also backs up our machines, so I asked them to do a restore of this guy's hard drives onto a network share. Of course he had multiple versions of all the code so it took me 3 to 4 weeks to figure out what was, I hoped, the closest version of what the code was that was running in production. Also fortunately for me the required changes were simple, so once I pieced together enough of the code to basically match what was going on in production, I could make the changes and get it out in time to meet the deadline. I immediately checked all of the code and my changes into source control.

    My take away from that is always use source control. Not to do so is like giving the next poor sap who has to work on your code an obscene gesture, should you just leave or die.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • If you deploy to production from anywhere besides a version control tool, you are doing it wrong.

  • below86 - Thursday, March 15, 2018 7:46 AM

    GeorgeCopeland - Thursday, March 15, 2018 7:21 AM

    The proper term for a developer who doesn't use source control is "amateur".

    WOW, I was an amateur for over 25 years.  Version control is very helpful, but I don't think it has any bearing on how good or great of a developer you are.  In my prior job I consider the developers i worked with to be great developers, and we did not have version control.  In my current job almost everything is version controlled.  Would I consider all of those developers great?  No I wouldn't.  I do think version control sometimes is used as a crutch for bad coding(developers).  IMHO

    I think amateur is a bit harsh, but if you're not using a VCS, you're not a professional these days. There is too much in the last 5-6 years with the growth of git for anyone to not be using a VCS. I struggle that colleges don't teach this first, requiring everyone to submit their solutions as a commit in a VCS. It's silly to send text files or executables around and poor training for developers.

    VCS could be a crutch, but there's no excuse not to use it. What should be happening is someone helping bad developers to become better.

  • Rod at work - Thursday, March 15, 2018 8:34 AM

    I am a firm believer in source control. When I came to this job I became an adamant believer in source control. One of the first assignments I was given was to update an ASP.NET web app. I think I had about 6 weeks in which to get it done. The problem was the original developer had some very odd views about his code. He didn't bother to use source control for anything. And when he left he told the Operations dept. to flatten his machine, which they did. But his machine was the only machine with the source code for the ASP.NET app. Consequently, there wasn't any source code available for me to work with. Fortunately Operations also backs up our machines, so I asked them to do a restore of this guy's hard drives onto a network share. Of course he had multiple versions of all the code so it took me 3 to 4 weeks to figure out what was, I hoped, the closest version of what the code was that was running in production. Also fortunately for me the required changes were simple, so once I pieced together enough of the code to basically match what was going on in production, I could make the changes and get it out in time to meet the deadline. I immediately checked all of the code and my changes into source control.

    My take away from that is always use source control. Not to do so is like giving the next poor sap who has to work on your code an obscene gesture, should you just leave or die.

    I have a similar story. I worked with a team of devs, 4-5, who were amateurs to the extreme. They used a VCS (SourceSafe), for both VB, ASP, and SQL code. However, they configured VSS to leave local copies on their machines to prevent commit conflicts. Lovely thought. Except, they'd checkout code to multiple folders as a rudimentary method of branching, and then deploy from their machines when they built features or fixes. No idea how the next guy cleaned the VB/ASP code. I took a week of no development and we decrypted all code from SQL Server (yes, they encrypted it), and stored that in a new VSS project. We then wiped .SQL files from every machine in the building to ensure we had a clean repo.

    Still shaking my head today at that one.

  • If amateur is too harsh, how about "hacker".

  • Steve Jones - SSC Editor - Thursday, March 15, 2018 9:06 AM

    I think amateur is a bit harsh, but if you're not using a VCS, you're not a professional these days. There is too much in the last 5-6 years with the growth of git for anyone to not be using a VCS. I struggle that colleges don't teach this first, requiring everyone to submit their solutions as a commit in a VCS. It's silly to send text files or executables around and poor training for developers.

    VCS could be a crutch, but there's no excuse not to use it. What should be happening is someone helping bad developers to become better.

    The Redgate DevOps 2018 report states that 52% of DB users who responded are using source control.  My experience has been that the willingness for source control and other techniques is there but the knowledge of "HOW-TO" is what is lacking.  When I started looking at DB source control I found that people were quick to harangue, dismissive of questions and not addressing some things that are pretty fundamental in the DB world.....like rollbacks.

    It is worth working through the issues and problems because the rewards are very great but it does take time to learn the processes and disciplines required.  I had quite a lot of frustration dealing with characters who once did a DB deployment to alter a table with 30 records in it and proclaimed that this proved that  changing any table would be trivial.  It's the same crew who state that you should only ever forward fix and that rollbacks are for brain donors.

  • It does take time to learn. That's why I wish we had more effort in pushing this earlier in careers, like ASAP in schools. At work, this should be part of onboarding, and I certainly would like more people to make an effort here. I really need to write some basic VCS concept stuff here.

Viewing 15 posts - 1 through 15 (of 25 total)

You must be logged in to reply to this topic. Login to reply