Branching to the Mainline

To many Mendix Business Engineers branching must be a new concept since it was introduced only the other day. Under the hood though, we find a well known piece of technology familiar to people who have used some flavor of revision control before. Subversion.

In short, it helps engineers develop on their own timelines in parallel with other engineers, and allows you to go back in time when your application was in different state. Its no time machine, but its just as exciting.

If you have encountered the practice of branching and merging, you will undoubtably know that there is no magical unicorns nor silver bullet solutions when it comes to how you approach your branch/merge strategy. It depends on the composition of your team and state of the tasks at hand. There is no one size fits all, only guiding principles. Perfection is impossible, but we strive for it nontheless.

Branching

At our current client, we use a very disciplined yet agile strategy for branching. Its a combination of 1 branch per User Story, a QA branch, and a Sprint branch since we follow Scrum practices. It helps with selective rollouts in relatively short sprints. Thats alot of branches, and before you think “Great Scott!” we don’t treat it as a rule that covers all instances. Its a guideline, although conventional wisdom dictates that one stay as close to the mainline as possible. In reality Business often decides what goes into production after UAT, since they have the habit of changing course in mid flight. When this happens its harder to dissect your changes in the model from other changes, the longer time goes by.

Always begin with the end in mind. Deciding on when to branch is during sprint planning 2. The technical nature of our user stories help dictate our delivery strategy. This ceremony is where discipline and mindfulness should be exercised. In our experience, when the tyres hit the road, working with the modeler takes least of our time, planning takes time. Planning helps you to think about your delivery and gives you a realistic reference with which you can manage a client’s expectation when it comes to timelines.

Being busy does not always mean real work. The object of all work is production or accomplishment and to either of these ends there must be forethought, system, planning, intelligence, and honest purpose, as well as perspiration. Seeming to do is not doing. — Thomas Edison

Merging

In simple cases this should be a breeze, but in other cases to avoid time paradoxes and polluted timelines, merging should be a team effort. Together we check whether what we commit is correct and resolve potential conflicts there and then. The modeler details nicely what has changed in a way you can quickly navigate.

Merging to the QA branch helps us with our UAT and merging the User Story branches to the Sprint branch gives us a dry run for merging to the mainline later. The rule of thumb is, only quality code goes into the mainline. And finally before we release, a versioned build is created.

At the end of each sprint, we reflect and adapt and make some minor tweaks to the process. This is in no way an exhaustive description of what goes on behind the scenes, but this its the general drift.

Your needs might differ slightly or completely. What is your strategy? Drop us a comment.

What if you are too fast?

Picture this. You are in a 120 km/h zone, you’re driving a car more capable than the speed limit and you need to be somewhere, but you are stuck in a traffic jam. This is familiar to most people: A traffic jam. What should be a speedy highway, is now the world’s largest parking-lot. The same thing happens when one has a more capable tool that demands a faster development pace for efficiency, but the current environment is in a dead-lock of inefficiencies and status quo’s.

Mendix Business Engineers have the opportunity of churning out functionality really fast. So fast, some regard it as disruptively fast. The environment cannot adapt quickly enough to change, especially if the organisation has processes built for traditional development teams. People with job-insecurity might perceive this as invasive, they typically do not like change and might even consider the current state of affairs as optimal

The cause of some dead-locks in IT, is dead culture. Tradition determines culture; it is distilled from experience and gathered over time and determines the way we work and the way we predict outcomes.

Here are some telltale symptoms of a bad cultural legacy:

• slowness to react or adapt
• taking little ownership over the domain
• lacking creativity and craftsmanship
• failure to understand business and a dependency on spoon feeding
• too many impediments caused by technological constraints
• an incompatible vocabulary with business
• a “not-invented-here” syndrome
• leaders threatened by new technology not their flavour and that use straw man arguments to keep the status quo
• an attitude that limits Business and often dictates what can and can not be done
• an environment where failure is punished and innovation can not happen.
• an environment with a gang culture where the choice morsels of knowledge of systems are only shared freely with those that comply with the gang’s culture and is liked by the alpha members of the pack

If these indicators match we can expect an environment where we need safety checks and processes that protects team members and dictates to the development team and business, in short and environment with lots of red-tape and ego’s. Processes and formalizations are always necessary, but the tail should not wag the dog. These should be support processes, not impediments. And often we find that in such environments the current “best practices” are not even blogged, documented or publicised and provides and insecure environment for any innovation to happen safely.

Most entrenched coders want job security, and want to be spoon-fed what business requires. They are low-risk – but not in a progressive way. Completer-finishers are crucial to teams but often fall into the low risk, pro status quo group that like security, getting things done – but generally happy to introduce technical debt at business level just to “get the job done”.

Everywhere we go, we see a general pattern emerging: Business is not happy with the pace of development that current IT shops can deliver. We see a similarity emerging with the construction industry where roles are clearly segmented in verticals and specialisation forces people to silo and only look down at their part. For instance, a brick layer only lays bricks and does not have the ability to read and interpret the architect’s plans. They rely on supervisors to take ownership and just do their thing. Plans can never detail everything and clients often feel cheated at the results they get. They feel they pay too much, get too little and that it it delivered late. The answer is typically to get new builders, new plans and better plumbers. And better processes. What we need is more than that. But a better process is a start.

Like Scrum. Implementing a better process is an excellent start. However, few seem to understand that it is a framework that requires customization to fit and optimally serve the environment. It can change the environment as its provides a division of roles with the minimum one should have to be successful in systems development. But we see environments where “the way we do things” are branded Scrum and is not allowed to change when required. The Scrum term gets branded against any disruptive force and Scrum’s rhythm and velocity arguments are used to structure teams in ways that do not make sense – when the goal is to develop great systems that satisfy the business requirements and where rhythm, velocity, measurability etc. should be supportive of this rather than the goal! The tail wags the dog. IT is there to write great systems that allow business to double their business.

Mendix engineering is fundamentally not traditional development. Mendix teams will find that they will have to challenge these processes to gain maximum efficiency and freedom to create business value. One needs to reform what IT means in the eyes of everyone else. This is a gigantic task and may take some time to break the deadlock depending on how agile your company is. It will be a change that will require time and effort and will probably upset people who are comfortable and in cozy jobs. An Oil Tanker takes a long time to change direction, and it is to be expected from other large organizations. Hang in there and work with lots of compassion, openness and communication, however do not comply with bad/non-optimal practices just to keep the peace. We have to put business first.

Mendix, as quick as it is, is not a silver bullet. The processes and approach around Model and Domain driven development needs reformation. Pick your engineers carefully, since they will be your first line of change agents and culture trend-setters, the ones who will share the vision of your business. If you want a comfort delivery zone and do not like change – look somewhere else for a solution as this is not a get-popular-quick scheme but a new and fresh business driven approach to churn out value with lots of changes to support that. It offers a new set of experts and building techniques that allows us to focus on what our clients wants and works best in an environment where ownership and initiative is encouraged rather than playing the blame game that results in dead culture and causes people to hide behind red-tape.