git Is Great With Obsolete Source Control Systems

git has a lot of traction in software development for many, many reasons. Clearly it’s a good tool to have experience with. Some folks are tied to legacy systems/processes that demand continued use of obsolete source control systems. It is possible to use git within that environment to a great advantage!

It’s very straightforward & simple: create a git repository (“local repo”) in a directory under source control (pick a directory with simple files and small in number); create a .gitignore file to trim the nonsense; configure the obsolete source control to ignore the .git folder & .gitignore file and you’re ready to go.

A system I’m familiar with has significant technical debt. Let’s assume a new feature X needs to be added. The source on my disk is updated from the obsolete system to be sure of currency. Now update git to get the local repo to the same baseline. I then create a git branch called “X-hygiene” to contain refactoring, code clean up, etc. Once that bit of work is resolved, I create the feature branch, “X”. This allows the refactored code to be the basis of X. As work progresses, additional hygiene needs to be done – no problem at all with git. Switch to the X-hygiene branch for more updates, switch back to X and merge the X-hygiene updates into X. Rinse, wash, repeat…

When you’re ready for the 1st code review, commit the X-hygiene branch for review. After that’s completed, the team can now review X as a delta from X-hygiene. X is committed into the obsolete system to complete the feature. (Don’t forget to merge X back into the git master branch.)

I’ve found other items to be very productive as well:

  • git branches allow for easy experimentation. Incredibly helpful when you’re getting into new technology or new functionality and need to learn a bit by experimenting.
  • Tortoise-git has very, very helpful diff tools. For example, it can quickly point out just the data that has changed inside hideous XML data file; do not discount how enjoyable these reviews become.
  • git local repos are incredibly fast, which makes branching a joy to use. This in turn encourages experimentation (learning) which is just too good an opportunity to pass up!

In summary, if you are trapped in the mire of a creaky, old nasty source control system, experiment with git. It is very heartening and dare I say, fun to use.


git Is Great With Obsolete Source Control Systems

Career Debt (aka Technical Debt)

Is technical debt relevant to individuals?

Several years ago, a jaded finance veteran pointed out: “You can never ‘stay the same’ in the market. As the competition makes incremental changes, you have immediately fallen behind as far as the customer is concerned. The compounding effect is huge.”

Common causes for technical debt include lack of training, poor processes, obsolete tools, etc. A team operating with this much baggage is really behind the 8-ball when it comes to delivering great services or an outstanding product. (OK, enough parroting of what others say.)

Technical debt will drive reduction in market value of your product. Revenue reduction is followed by cost cutting, which is often job loss. Even if you’re the star of the team and will be retained past the initial cuts, the trajectory is clear.

Whence you find yourself jettisoned from the safe confines of the good-old-days, how do you plan on marketing your skills & knowledge? Everything you know is obsolete or not acceptable in today’s market. Your expertise in an obsolete product, once valued so highly, is completely worthless! That expertise that made you the star has zero value. Ouch.


Career Debt (aka Technical Debt)

Delete Code to Improve Team Performance

A lot of legacy code can be really bad. By the time you have gone through it to understand what is going on, a considerable investment of time has occurred.

Consider when obsolete or unused code is reached; what should you do?

Old-school folks may be inclined to let it be. They know the answer and move on to something else – let it continue to rot, it won’t hurt the product. If they are feeling especially helpful, a comment may be entered to acknowledge the irrelevance.

If you delete it, you have immediately shared that knowledge with the rest of the team! The time you “wasted” is forever saved. This is a great step, as the compound interest of this recovered over time pays back many times over.

Delete Code to Improve Team Performance