Boundaries in Dev

Perhaps one of the few common tool types for all developers is a change control system.  During my career, I have used a progression of them: SCCS RCS ClearCase CVS and SVN Serena Dimensions Git (GitLab and BitBucket) The key features of a version control system are: Keeping all versions of a file Allowing you to tag or label a set of file versions Supporting concurrent editing by multiple people It's this last item that starts a lot of very passionate points of view.  You will hear statements like: "You should only develop on master" "You should/shouldn't have a branch for feature development" What you need to keep in mind is that the right answer for a particular development environment will depend on many factors.  Let's talk about a few of them. Deployment size: the number of dependencies increases with deployment size.  What is reasonable for a micro-service in a single language for a single deployment is not going to be t...

In the mid-90's, I got to become experienced in CORBA distributed programming environments.  While it's considered a dead technology with a lot of flaws , I would like to look at it specifically at it from a boundaries point of view. With the advantage of hindsight, we can look at which characteristics of a distributed programming environment: Interface Definition Language (IDL) - is not a deal breaker.  If you look at current environments like gRPC, the use of a language independent definition language allows wide adoption.  The ability to do code generation for your interfaces ensure that you can implement clients and servers with static type checking (if your language supports that). At the same time, JSON is also widely used is REST implementations.  So, another successful alternative is an interpretive on the wire format. Leaking language details into other implementations is not good.  Anyone who implemented a CORBA system would have to learn and und...