It’s time for Check In to Check Out

ChekovAh, the twin pillars of Check In and Check Out, titans in the CAD pantheon and usually in the first breath or two of any conversation about Product Data Management (PDM).  Long has this technique been the lynchpin in regulating data integrity for revision controlled items in a multi user environment.  Undoing such a core feature seems like utter madness.  Yet, it seems the world is changing.  Social engineering projects are challenging the classical tenets of revision control, and there is growing sentiment that PDM as it stands today is insufficient for the future.  At the center of this changing sentiment, are the branching and merging methodologies widely used in Software Configuration Management (SCM) with rather ubiquitous tools like Git and Subversion.  Guess who’s coming to dinner?

Back in ancient times, last Tuesday to be exact for some, CAD engineers would bang rocks together to make files, files which had specific ownership in native directories.  Ownership and exclusive access were the primary means of determining who worked with what to mitigate a total free-for-all.  Some engineers, over time, became rather possessive and became attached to this model.  In some cases this ownership model was replicated in PDM exactly, requiring ownership to be transferred from one user to another before access to change a file was granted.  But there was clearly a better way.  By offering a central repository, PDM removed the need for outright ownership to determine change rights.  But a mechanism was needed to keep two people from working on the file at the same time – and that mechanism was Chekov, er – Check In and Check Out.

Changing a file required checking the file out.  Sometimes the process was implicit (handled within the CAD system) other times the process was explicit (requiring manual intervention).  Once the changes were completed, the file was checked back in.  For some  engineers overly attached to the prior ownership model, the fact that anyone could mess with their nuclear wessels was downright frightening.  So it wasn’t long before particularly obstinate engineers would devise the camp out  – essentially sitting on a check-out on purpose.  Anyone questioning the camp out would be met with glaring.  The issue was quickly rectified with reporting and automatic check-in.  It seems so ridiculous that the check in/check out model was resisted in some circles, now that the mechanism is quite universal.  It’s in every CAD management tool, document management app, and yes, even Sharepoint.

So now that everyone’s comfortable with check in / check out it may very well be time to throw it all away.  Right into the ocean.  The limitation of check in and check out is the serial nature of change.  Have something that needs to changed often by lots of people?  Well everyone just needs to get in line and take numbers.  Now serving #1138.  It’s just like the DMV, and we all know the DMV is the height of civilization.  The answer is to just let change happen.  All at once.  Which is of course, madness.  Or is it crazy like a fox?

The answer may lie in adopting software development methodologies, namely branching and merging.  Case in point a snippet from a GrabCAD interview with open source engineer Matthieu Lapeyre:

“What do you think PDM solutions lack that you need?

PDM is missing the ability to branch, fork and make merge requests. With an open source project, especially an open source robot, people are making their own modifications but they don’t have editing rights for the main repository. They need to be able to make merge requests- send notifications from their repository to ours so their changes can be merged upstream. That’s better than everyone working on the exact same version.”

But let’s be real about this, Keptin.  Merging and branching is hard enough with just the text file components in software, what’s to be done about CAD binaries and other file types?  It’s a little more complicated that rerouting power from the phaser banks.  Up until this point, the answer has been to run away.  But I don’t think it’s an impossible feat. That’s a technology worth working on. It’s high time someone started attacking this problem directly.

Google Docs, for example, has simultaneous edits, provided you author the documents using their web tools – but their vision of revision control is lacking in fidelity.  In the CAD space, at least one major player is thinking at least peripherally along these lines.  Just recently Chad Jackson penned an article describing capabilities in ENOVIA V6 where metadata elements associated with CAD are essentially decimated as separate database objects to allow simultaneous editing.  Here’s a passage that explains the idea:

“The important point here is that those changes occurred serially, one after the other. With two users, that may not be a big deal. But once you scale that up to, say, twenty users collaborating on 100 parts, users need to get in line to modify a part. Or worse yet, users simply own a part with no one else touching them, eliminating any collaboration.

With Dassault Systèmes’ approach, the need to explicitly coordinate change or wait in line for modifications is removed. All that meta-data can be modified simultaneously and independently. Design teams can work more collaboratively and quickly.”

This particular concept is not without its serious problems, and is not branching and merging outright.  But still partial credit for some incremental ideas in trying to solve the problem of serial change.  What do you think?  Are software branching and merging concepts the future of not only social engineering, but all hardware engineering?  Or are we better served by blowing the idea out the nearest airlock?

  • Ryan

    Great to ready your articles. I count on them to make me smirk at least once.
    Anyway, are people really waiting in line to work on models or are they waiting in line for the change process (your DMV) to complete? If this is the case, then we need to look at our DMV instead. Agree?
    I also thought that Siemens NX had the ability to define a zone/area of a model and allow multiple users to work on the same model- I’m not sure but I thought I read that somewhere.

    • Thanks Ryan, I get paid by the smirk… :-7

      Agree that part of the problem is that blasted DMV – because it ramps up the consequence of change to the point that creation of a bunch of casual changes that may or may not be discarded is burdensome. But there is also a fundamental technical disconnect for CAD (and really all documents). The DMV has remained very linear for precisely this reason.

      Up to this point it’s only been possible to simultaneously work on something through decimation – i.e. this assembly is broken up in to piece parts or this document is broken into section sub-documents which can be dolled out for individual editing. But the moment paths cross – i.e. two different edits on the same part or section and it’s back in line.

      Think of the classic engineering trade study – you might have 3 different people cook up three slightly different variations in parallel, with the intention to continue with the best one, only to later have to change gears to what was second best. With today’s tools you can save as under new ID’s for the branches, but re-merging or changing gears to an alternate branch can become difficult to impossible. Software development, in contrast, works far more naturally with variability. When it comes to the new social engineering trend on the rise – absolutely everything is worked on in this way.

      As far as NX, you can have multiple users work on individual parts in an assembly by opening a parent assembly by proximity and editing those parts in context, but you can’t have two people on the assembly itself.

      • Ryan

        I did a bit more checking and yes, Siemens does allow for multi-user modeling. It’s called modular modeling.

        “Modular design NX introduces a modular design capability that simplifies modeling and editing of complex designs, and enables parallel work by multiple designers. With part modules, you can subdivide designs into isolated, selfcontained functional elements with modular interfaces in an organized structure of re-usable design elements with embedded intelligence.” What’s New in NX 8

        It’s not fully what you describe but is a good start. It would be interesting to know how this has progressed in NX8.5 and NX9.

        • Ryan, looks like I missed your last comment. Modular Design appears to be slightly tweaked existing functionality packaged under a fabulous new marketing name. What’s shown in the demonstration is actually capitalizing on WAVE, and this type of approach (sharing reference entities between users and merging the pieces at the end) has been possible for years. They’ve just made it slightly more accessible with a “modular part” container.
          That being said, I still consider this a form of decimation. Planning the division of labor is necessary ahead of time. The demo shows one person working the ribs of a bulkhead, while another works an end fitting which is then boolean’d together at the end. A much more interesting example would be different people moving ribs around in different directions and angles while the thickness and fillets are changed by a third – not quite as easy to plan.

  • anniv bm

    The main problem is not to know what amazing thing we can do with a software but what is my responsibility in the design process. This responsibility has consequences on the data everyone can modify or can’t ; better said had to modify or hadn’t.

    • Anniv, I think your point is the process is there to prevent chaos if the responsibility for change isn’t clear, is that right?
      Imagine removing the consequence of change. Such that anyone can make changes in parallel, and any of those parallel branches can be selected as the truth, reverted, or selectively merged. I.e. not letting the mechanics of the change process (or perceived ownership and responsibility) limit the potential for change. Sounds crazy doesn’t it? Software developers have known this well.

  • Pingback: The Death of Change Management | E(E)()

  • Pingback: The Day the Strength of PDM Failed | E(E)()

  • Pingback: Do you believe in Engineering “Real time Collaboration” Neo? | E(E)()