Why I prefer pessimistic merging

Even though I trust my team.

As a technical lead, I think code reviews are essential to ensuring the quality of the code. On a project I worked on, due to changes in Project Management, I ended up switching between code reviews as standard and code reviews by exception, and in every case, releases delivered with code reviews baked in had fewer bugs, and were far more likely to meet deadlines.

I believe that code reviews done after integration have roughly the same benefit on these metrics as no code reviews at all. Although this guy prefers optimistic merging, I’m not convinced, and I think pessimistic merging is the only way to review code, especially when automated testing and static analysis are part of the review process.

However, my experience is with working with small-ish, cohesive teams, rather than open source projects seeking new contributors, so please bear that context in mind.

• It’s easier to fix problems pre-merge;
• Blockages pre-merge are far easier to detect (kanban!) – fix the bottleneck, don’t break the process;
• Code reviews are the process by which the team takes ownership of the code;
• The code remains continuously shippable;
• Each code review is a checkpoint for discussion, and segways into refactoring and other improvements.

Accessible for everyone

I don’t know if you’re familiar with Isofix child seats, but you spend all your time figuring out how to fit it correctly in one car, then you have to switch to another car and it just doesn’t seem to fit the same way. (Browser manufacturers, take note).

A safely fitted child seat has green flashes that appear to show that the seat is locked into position, and they’re easy to check by inserting your eyeballs in the 3cm between the edge of the seat and the car frame (I admit this is slightly easier in a 5-door car where the frame is removable via a hinge).

For those without detachable eyeballs, this can be a challenge.

But the car seat we have has a nice little accessible touch. The green flashes are hook shaped, and recess into the seat when the seat is unlocked, so if I can feel a hook on the side of the seat, I know that the seat is securely locked.

I don’t know if the designer deliberately chose to make the safety catch non-visually accessible, but I am very grateful that they did. It has saved me a lot of sore heads and worry.

I assume that the designer in question was not the genius who decided that websites with infinite scrolling should have footers. *scroll down* ah, site map *click* *new content loads* *wrong page opens*. That designer should find a bothy somewhere and stay away from computers for the sake of everyone else.

Be accessible. Looking snazzy is one thing, but if you really want to be appreciated, think about the little touches that make the interactions wonderful, and make something that’s otherwise impossible, easy.