Bringing discipline to development, without causing pain

There’s that question you’ve always wanted to ask in an interview when the dialogue has gone really well and you know you’re about to get offered the job, but you don’t want it anyway.

Interviewer: “Great, so do you have any questions that you would like to ask me?” Candidate: “Well, if I’m traveling in a car at the speed of light and I turn the headlights on, does anything happen?” Interviewer: “Gosh, I’m not sure.” Candidate: “Okay thanks, you can keep your job in that case.”

The point is that the workforce is starting to dictate the way it wants to work on its own terms. From the undeniable rise of millennials and their preferred methods for hot desking and so on, to the ‘phenomenon’ of Bring Your Own Device (BYOD) and all the infrastructural changes it has necessitated… the users, increasingly, get to call the shots.

Systems of meritocracy rule

What this means in practice is a new set of defining principles upon which the software application developer builds his or her system faith. Systems of meritocracy that hinge around the community contribution model of open source are blowing old school thinking out of the water. Seniority and company rank comes from what you have achieved and what value you have added, not from who you know and where you went to school.

Equal levels of reality are found at the tools level where we find that collaboration is everything -- and we do mean absolutely everything. There’s no I in ‘team’ and really there are only four in ‘collaborative peer code review and issue tracking system’, right?

This is an age of connectivity where a silo-based or compartmentalised approach to any level of software application development must only be undertaken if that ‘compartment’ is integrated, collaboratively connected and ultimately structured around an agreed hierarchy of privileges and access. The popularisation of container-based technologies in programming is only popular because containers (in theory at least) perfectly interconnect.

Stung by GitSwarm, in a good way

Looking at contemporary approaches in this space, Perforce’s work to partner with GitLab as a web-based Git repository manager and produce the GitSwarm ecosystem is a case in point. Perforce’s Helix is said to give developers the pure Git-based workflow they love, while making projects ‘easy-to-manage’. A team’s work is automatically synchronised to the Helix mainline repository as GitSwarm provides a platform for code reviews, comments and tracking issues.

That simple but oh so often-overused term ‘easy-to-manage’ is important. This is about taking Git to the enterprise level. Once again this is about balancing developer preferences with the needs of the enterprise.

If we don’t get this right then a) the enterprise software shop is badly served by the developers who should be luxuriating in the glow of a job well done and b) the developers end up thinking that the team leaders don’t know what happens when a car traveling at the speed of light turns its lights on. The end result of the latter, obviously, is that developers don’t want to work for you anyway.

Technical breakdown

Let’s break this down technically to examine the root of the issue. In doing so we may well find that the bridge between freedom and control tells us more about the shape of enterprise software application development than we first thought.

We can say with some certainty that developers like using Git as a repository manager. They like it because they are attracted to its distributed workflow capabilities, which allow them to frequently switch ‘contexts’ and development code streams. They like this lightweight approach to local branching because it allows them to progress different application elements independently, but still, in unison with (and close proximity to) the main code base in development.

So far then, what’s not to like? We’ve got control, flexibility, and management in a lightweight wrapper that says ‘user friendly’ right there up on the front.

But this is enterprise development and although the inherent branching capabilities of Git are perhaps its defining feature, we need to explode outwards from an individual single developer’s desktop to a much bigger tree of branches.

It is at this point that we start to understand how a powerful feature like branching can start to become a hindrance, or perhaps we should call it a ‘corporate encumbrance’ (in terms of enterprise-level controllability) at least. In a wider enterprise development environment do we know who gets to define and determine the final branching structure? Do we know what the protocol is for sharing experimental branches with colleagues? Where should the work be reviewed? When should those branches’ contents be brought back into the master? Come to think of it, how should process itself be done, given that the Git community remains polarised over merge versus rebase techniques?

Tools like GitSwarm, GitHub, GitLab, or Atlassian Stash (recently renamed ‘BitBucket Server) implement simple workflows around pull requests to supply some of the answers. But the call to action here needs to revolve around defining branching strategy at the outset before a project commences and making multi-disciplinary collaboration the norm across the breadth of the development shop.

According to Perforce, the logical approach to branching inside Helix GitSwarm is one where we can protect a particular branch by limiting access. This prevents pushes from everyone except ‘masters’ (or team leaders), prevents anyone from forcing a push and prevents anyone from deleting it.