March 15, 2018 at 9:45 am
Steve Jones - SSC Editor - Thursday, March 15, 2018 9:06 AMbelow86 - Thursday, March 15, 2018 7:46 AMGeorgeCopeland - Thursday, March 15, 2018 7:21 AMThe 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.
Amateur or poor or 'not a professional', any can be offensive. We've had this same argument when I was at my prior job Steve. If as a developer I try and push that we need a VCS, and nothing happens, does that make me a non-professional? If as a developer I can't load any VCS software to my machine, even if it's free, does that make me a non-professional? Too many times on this site broad statements are made by people looking down on the rest from their 'ivory towers'. I am in a shop that uses a VCS, it is great, wish I had it at prior job. But you can't judge someones skill level by whether or not they've used a VCS.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
March 15, 2018 at 10:03 am
I think that professionals should not take forum comments personally. In my opinion, the concept of DevOps is a refinement of Agile methodology. Fifteen years ago, Agile was an opinion. In the intervening years it has proven itself. In other words, IT professionals should be at least aware of DevOps. Like Agile was 15 years ago, the principles of DevOps are still evolving. One of its principles is "Version everything". As a professional, the correctness of this statement is obvious to me. Disagreement with this is just not substantive, it is similar to arguing about the shape of the earth.
March 15, 2018 at 10:41 am
What I'd say is there is a difference between knowing and wanting to use a VCS and not being able to because of work restrictions. You might be a professional, but certainly if your org doesn't allow a VCS, then they aren't providing a professional environment.
If you take offense, I'm sorry, but making a conscious decision to avoid a VCS in software development is just silly, short sighted, and certainly not professional. You might be ignorant, and you might be able to get code written, but this isn't a sign of a professional environment.
This isn't an ivory tower argument. It's a solid view backed by tons of experience from the industry over time.
March 15, 2018 at 11:12 am
Steve Jones - SSC Editor - Thursday, March 15, 2018 10:41 AMWhat I'd say is there is a difference between knowing and wanting to use a VCS and not being able to because of work restrictions. You might be a professional, but certainly if your org doesn't allow a VCS, then they aren't providing a professional environment.If you take offense, I'm sorry, but making a conscious decision to avoid a VCS in software development is just silly, short sighted, and certainly not professional. You might be ignorant, and you might be able to get code written, but this isn't a sign of a professional environment.
This isn't an ivory tower argument. It's a solid view backed by tons of experience from the industry over time.
Using a VCS is not an ivory tower argument, never said it was. But to label developers that have not used VCS as Amateur/poor/not a professional/hacks, that IS an ivory tower argument. Now calling someone who chooses not to use VCS any of those, I can agree with. You preach to be inclusive of all not matter skill level, but I could see someone taking offense to those statements. I've been around long enough to know I don't give a 'rats A' what anyone thinks of me or my skill level. Maybe instead of calling it 'Great developers use source control' you should say 'If you want to be a better developer, use source control'. Try leading people to it, instead of beating them over the head with it. Just my opinion, over and out.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
March 15, 2018 at 11:23 am
You are confusing professional and ivory tower. They are not the same thing.
March 15, 2018 at 1:47 pm
David.Poole - Thursday, March 15, 2018 2:42 AMThe 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
Very comprehensive list. I'd add to this list the ability for multiple developers to work on the same code files, to avoid stepping on and overwriting each other's changes. Similar to branch/merge, but includes people working at different times on the same code even without the need to merge.
I've succeeded in getting my team to adopt using source control. The payoff was immediate, even though it was a bit of a struggle to get compliance at first.
March 16, 2018 at 4:16 pm
I use Source Control not just for Code. I use it for Documents and even when I am writing letters.
It not only provide a backup in case of emergency, but allow my to go back and look at other versions in case I change my mind.
Source Control is as Important as Backup. Use it and Live long and Prosper.
March 18, 2018 at 7:58 am
Steve Jones - SSC Editor - Thursday, March 15, 2018 9:10 AMRod at work - Thursday, March 15, 2018 8:34 AMI 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.
WOW, that's pretty complicated!
Kindest Regards, Rod Connect with me on LinkedIn.
March 18, 2018 at 8:08 am
GeorgeCopeland - Thursday, March 15, 2018 10:03 AMI think that professionals should not take forum comments personally. In my opinion, the concept of DevOps is a refinement of Agile methodology. Fifteen years ago, Agile was an opinion. In the intervening years it has proven itself. In other words, IT professionals should be at least aware of DevOps. Like Agile was 15 years ago, the principles of DevOps are still evolving. One of its principles is "Version everything". As a professional, the correctness of this statement is obvious to me. Disagreement with this is just not substantive, it is similar to arguing about the shape of the earth.
Not everyone is allowed to practice Agile development, such as where I work. I do think most, if not all, of us are familiar with Agile, even if we can't practice it.
Kindest Regards, Rod Connect with me on LinkedIn.
March 19, 2018 at 6:29 am
dstrickrott - Thursday, March 15, 2018 1:47 PMDavid.Poole - Thursday, March 15, 2018 2:42 AMThe 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
Very comprehensive list. I'd add to this list the ability for multiple developers to work on the same code files, to avoid stepping on and overwriting each other's changes. Similar to branch/merge, but includes people working at different times on the same code even without the need to merge.
I've succeeded in getting my team to adopt using source control. The payoff was immediate, even though it was a bit of a struggle to get compliance at first.
I would say that so many don't understand how powerful working on the same piece of code is important to do with version control. But this is one of the only issues you face without doing it as most of the benefits are already easily controlled without version control of the DB. This is why I think so many don't use version control with the DB versus code outside of the DB. In meaning, the source is already backed up with the data and you can still separate production from dev easy enough to ensure no one is committing changes directly to production.
But even if you give every developer their own dev environment, still doesn't change the fact that anyone working on the same piece of code is going to have conflicts when they merge.
March 19, 2018 at 2:23 pm
xsevensinzx - Monday, March 19, 2018 6:29 AMBut even if you give every developer their own dev environment, still doesn't change the fact that anyone working on the same piece of code is going to have conflicts when they merge.
We do occasionally get merge conflicts but in Git they are fewer and easier to resolve. Git was written with distributed, disconnected development in mind.
I've found that you have to adjust your processes to play to the strengths of your toolset. Frequent check in/merge enabled by a comprehensive automated test regime reduces instances of merge conflicts still further. We found that small, frequent releases allowed us to progress much faster than previous practices. So much so that for the first time we were on the front foot when discussing requirements with our business colleagues. We were even able to pay down a substantial amount of tech debt and start considering more innovative approaches. Of course the reward for good work is more work
Viewing 11 posts - 16 through 25 (of 25 total)
You must be logged in to reply to this topic. Login to reply