Source Control, Version Control, Change Control, and the Underlying Disciplines Thereof
So, out there in the world of developers, Delphi and others, there are many schools of professionalism, around:
1. Dude had a bad day and lost data. Decides to up his game to using Zip files. (For most of us old timers, I hope this day was back around 1991 for you.)
6. The Dude and Team, do CI, and honestly tried to start Unit Testing, but that never really worked. There are millions of warnings and hints in the code. When the code somehow builds without an error, we hand it to QA then ship it. If you don't have dedicated QA people, you are still level 5, hire a QA, and have CI, and you're level 6. Congrats, you're probably above average in the Delphi world.
So far, I'm not aware of ANY delphi shop that can claim to be in category 10, for even the top four largest codebases at your company. Typically a few products are in good shape, and the others are pretty rough. From comparing notes with other Delphi professionals, most best of breed Delphi shops are probably in categories 6-9 above, all of which are Pretty Good to Really Good, in my opinion.
- Version Control Practices
- Continuous Integration Practices
- Release Management and Change Controls
Let's imagine there's a dial from 0 to 10, and at each number on the dial, there's a developer or team that is functioning at that Level of Versioning/CI/Release/Change practices.
0. Dude with laptop, ships code from his laptop to customer pcs.
0. Dude with laptop, ships code from his laptop to customer pcs.
1. Dude had a bad day and lost data. Decides to up his game to using Zip files. (For most of us old timers, I hope this day was back around 1991 for you.)
2. Dude sees the beauty of being able to check in, revert, commit. Dude is saved and has seen the Version Control System light. (This happened to you in about 1999, hopefully and your first version control system was Visual Source Safe, hopefully you are not still using that.)
3. Dude realizes that checking in frequently is great. Dude has not realized that Branching is useful, or is using a tool in which branching is not very useful (like Subversion). Dude needs to learn new tools and practices, but doesn't want to.
4. Dude is member of a team of Developers. This team works well together, so they have to know what branches are, and merges. None of them know what Continuous Integration is. The team builds and ship from a designated lead developer PC.
5. Dude & Team had a bad day, and learned to love CI. The CI system is a bit sad but hey, we've got one, and that makes our Kung Fu better than teams that don't. No longer does The Dude ship code from his/her laptop to customers.
4. Dude is member of a team of Developers. This team works well together, so they have to know what branches are, and merges. None of them know what Continuous Integration is. The team builds and ship from a designated lead developer PC.
5. Dude & Team had a bad day, and learned to love CI. The CI system is a bit sad but hey, we've got one, and that makes our Kung Fu better than teams that don't. No longer does The Dude ship code from his/her laptop to customers.
6. The Dude and Team, do CI, and honestly tried to start Unit Testing, but that never really worked. There are millions of warnings and hints in the code. When the code somehow builds without an error, we hand it to QA then ship it. If you don't have dedicated QA people, you are still level 5, hire a QA, and have CI, and you're level 6. Congrats, you're probably above average in the Delphi world.
7. The Dude and the Whole Team are conscientious about cleaning up hints and warnings and is working on getting code under unit test. This is now better than about 60% of delphi shops.
8. Dude and Whole Team Always know what was shipped to customers, as each version like Version 1.6.7.85080 is known to correspond to a certain CI build which in turn corresponds to a known revision in version control. All the executables are re-tagged with versioninfo updating tools during builds. This is now better than about 70% of Delphi shops.
9. All the prior best practices are followed and also, All code that we build also passes tests or it doesn't go to human QA. These tests cover 10% or more of real bugs that QA would find. You are probably in the top 20 best Delphi shops in the whole world.
10. All the prior best practices are followed and also,All code that we build also passes tests or it doesn't go to human QA. These tests cover 80% or more of real bugs that QA would find. You are a unicorn, and you probably don't exist, or you're working in Go or C++, not Delphi.
10. All the prior best practices are followed and also,All code that we build also passes tests or it doesn't go to human QA. These tests cover 80% or more of real bugs that QA would find. You are a unicorn, and you probably don't exist, or you're working in Go or C++, not Delphi.
So far, I'm not aware of ANY delphi shop that can claim to be in category 10, for even the top four largest codebases at your company. Typically a few products are in good shape, and the others are pretty rough. From comparing notes with other Delphi professionals, most best of breed Delphi shops are probably in categories 6-9 above, all of which are Pretty Good to Really Good, in my opinion.
But Pretty Good and Really Good is still basically much lamer than many Go, Ruby, and Java open source projects out there, that you can go inspect and see, are being built with levels of professional practices that far exceed what I am personally aware of within Delphi based teams. If your Delphi teams blow away all the rest, please please write a blog post and explain how you do it.
Some truly impressive open source projects you can observe a whole higher level of practices going on include the C# roslyn compiler and the .net core open source project, the gitlab version control system (built in go, and ruby), Google Chrome, Firefox, and SQLITE, which has a truly impressive set of unit tests and change control practices around its C/C++ core.
I want to move on to the question of WHY the best practices matter.
A lot of the principles that underly the best practices above should be obvious to most professional software developers, but sometimes these principles are left implicit, and not spelled out.
Here are some principles that lie beneath the practices above. I have seldom worked on a team that couldn't do something a bit better. The best teams were always asking, "how can we improve?". The worst teams were always trying not to think about it.
1. Change Control Disciplines : We want to not make accidental changes, or even have people intentionally commit things, that were not wanted. How are we going to minimize risk of accidental or just random developer "felt like doing something" and that ending up in our product without anyone being aware, or testing for it?
2. Quality Control Disciplines: How do we ensure we know the risk and the proper testing scope, for any release of software we work on?
3. Version Tagging Disciplines: Does everything contain what it says on the tin? Is version 1.0.3.10231 enough information to recover the exact source code set that was used? (If you used CI, and build 106 in jenkins, became installer-1.0.3.10231 , and you can see which git or svn revision that was, you can recover sources to any version in the field, and accurately patch it.)
4. Code Hygiene and Code Quality Disciplines : Do we fix warnings (especially the ones that lead to direct bugs, like uninitialized local variables) before we ship to customers? Do we keep warnings and hints very close to zero so that really bad stuff doesn't hide "in the weeds" in plain sight? Once all the real ugliness is out of the way, some teams graduate to Code Smells, and Refactoring, to get the architecture in a better place so the product can grow and change and not collapse under its own weight. Code Hygiene and Code Quality disciplines are a never-ending asymptotic series of goals and ideals, but within those disciplines is a path out of drudgery and fire-fighting leading towards coding quality software that your customers will love.
There are more details and things to say about the kinds of disciplines involved in the points above, that are not even talked about, there's a lot to be said about how to move from ball of mud (classic delphi) to TDD and well-factored code that is not a ball of mud. Those are topics for another day.