Month / December 2015

by programx360

Pass the fork

Teams often work on shared code, shared resources and in shared time. We have ways of managing this, such as source control, one of the first requirements for software development maturity (falling within Levels 2 to 3 of the CMM for Software). However, not everything is easily integrated into such a process.

Developing on the example of source control, source control presents challenges that the mature team will be able to identify and overcome through the use of best practices or their own devised and agreed processes. Shared assets such as legacy systems, premium-licensed resources or even databases often exist outside of source control leaving the team requiring confidence that one developer’s work on that shared asset won’t affect others.

Meet the fork.

The DB Token of Power ("The Fork")

With the fork, a team member can wield power of access to a contended or non-source controlled asset such as database schema changes, SharePoint server configuration, leverage of a single-user licence service or other lock-required activity. The fork acts as a physical action and visual cue in the physical world, representing the reality within the virtual or abstracted world of source code, databases and servers. As a team member reaches for the fork, their wishes are explicit (“I have the fork”) and may be “blocked” by any other team member (“Oi, hang on, I need to do something first”). Without the fork, no changes may be made – or would be expected to have been made by the rest of the team.

Use of a token in this manner is predicated on the collaborative capabilities of the team, perhaps requiring that the team are co-located, small and cohesive. Such team environments aren’t always possible or available. Teams that are not co-located, are perhaps too large (spanning more than one pod of desks) or lack a cohesiveness that is conducive to casual conversation would inhibit the use of such a token; though in this case, one must answer much larger questions about why are these people working on contended assets?

There are alternatives. Use of a shared chat channel for the team such as Slack with an agreed protocol (even descending to the “claim” protocol introduced in The Walking Dead TV Show) would overcome the overly-large, distributed and communication-inhibited team; though this would require a level of buy-in or enforcement by a commonly accepted leader.

We’ve used the fork to great effect. Merging of sensitive assets such as Entity Framework .edmx files (this project has not yet made it to Code-first) can result in a whole world of pain if two developers tackle two work items that are either contradictory or contended. It’s simple and promotes added cohesiveness within the team. Our token was chosen based on what was sitting in one of our drawers and this remains a shared experience within the team and contributes to our mutual social credit.

Of course, you don’t need to use a fork, any token will do, so long as the understanding across the team is consistent and mutual. Such tokens have been in use for years. Ever since the 19th century, and remaining in use even amidst today’s modern computer-controlled signalling, railways have used the token to guarantee safe access to controlled sections of track to prevent collisions.

 

 

 

by programx360

Source control your relationship

pipe-cleaner-people-1177056-640x480An interesting parallel was drawn by a colleague recently between relationships with your significant other and source control. Both need total engagement by all parties and both can quickly unravel when a lack of commitment or adherence to the agreed guidance and conventions isn’t all it could be.

There is the sitcom-esque “commitment issues” whereby either party is afraid to really commit to a relationship either monogamously or sealing the deal through marriage. Programmers who exhibit a tendency to hold on to their code, avoiding regular commits, store up problems both for themselves and their team.

Maybe your other half feels that she has been put on the shelf, forgotten about and fleetingly appearing in your life as you pass by over dinner or scanning the repo. And you better make sure you get your [file]names right first time if you want to avoid a rapid appearance of irreconcilable problems.

Source control remembers everything you did, all your commits, experiments (branches) and log comments (not as private as one might like). “She” is equally able to remember all your mistakes with unnerving accuracy. Your branches (experimental flings) are on your permanent record, as are your seemingly innocuous comments logged (“I’m fine”). When differences approach the irreconcilable, you start reaching for the Patches.

Any experiments you may have on your branches/flings, are always a time of nervousness to merge back into the trunk/relationship and can rarely be fully re-integrated. Conflicts and lost assets are inevitable. “She” prefers exclusive checkouts, you might prefer a more … distributed approach.

Perhaps where the metaphor starts to fail is the real-world relationship’s difficulty of reverting commits. A programmer can quickly back out of some embarrassing moments in code with a right-click, returning silently to the state of their source and team relationship as if nothing happened. On the other hand, “she” remembers all your mistakes and your attempts to repair them.

By the way, to save embarrassment, this tongue-in-cheek parallel is drawn with no reference to any relationships past or present, real or imaginary. So, no need to perform any Diffs here.