Hiding Perforce from Users: Vanilla vs. Custom
Experienced engineers tend to have good CM instincts. I like to think CM knowledge and practices help put a solid engineer at the top of their craft.
There's a common theme that occurs in some enterprise Perforce environments, that they'd rather hide Perforce from users -- especially the junior ones. They pay them to code, and they don't want to spend time teaching them anything about version control beyond, "check out, check in." They actively avoid training on the version control system specifically, instead training them on internal processes codified in layers of wrapper scripts. Wrapper layers obscures much of Perforce functionality for the benefit of simplicity.
This surprised me at first, but it shouldn't have. Back in the day, as a ClearCase consultant, I often said, "If one my developers needs to look at a config spec to do their job, then I'm not doing my job." I was OK with letting power users use the tool to its fullest advantage. But we needed to prevent novice users from making high-impact mistakes, like setting up a workspace incorrectly or "driving through the hedges" (merging along an ill-considered merge pathway).
The rough equivalent of a ClearCase
config spec is a Perforce
client spec. It's one of the fundamental things you need to understand to get started working in Perforce. Or ... not. Administrators at some large sites tell us they'd rather not train users to learn any more than they absolutely must to get their jobs done. The mantra is pretty much, "Check out, submit, and that's it!" It's fair to expect a user to understand that they're working on "Project X", and to know there's some workspace-thingy they're using, but that's all the admins want the user to need to understand.
I fell in love early with Perforce's pay-as-you-go trade-off between sophistication and complexity. Perforce is easy to use if your environment is simple, yet has the sophistication to grow so that it can fit the process and workflow standardization needs of an enterprise. I haven't found the need to write thick layers of wrappers like I did with ClearCase, but you still have layers, albeit thinner, in many Perforce shops.
Layers: Good, Bad, and Ugly.
Sometimes these layers are viewed as a tremendous productivity-enhancing assets to the organization. Based on an understanding of an organization's needs, workflow, and intended usage, tools can be written that build those assumptions into triggers and systems that interact with Perforce. That makes life easier for users.
Other times, the layers are viewed as complex beasts that become difficult to maintain over time. The thicker the layer, the greater the complexity. Greater complexity usually results in several management issues:
- Greater the dependency on a few key individuals (leading to nightmares when they leave).
- Deferring Perforce upgrades increases time-to-value of Perforce features.
- More moving parts = more things that break.
My own advice: Layers are simply too helpful and valuable to eschew them. Go forth and write your layers of triggers and scripts and other extensions to Perforce! But, bear in mind:
- Think thin. Each time you put something between Perforce and the user, make sure it really adds value.
- Consider the Perforce interface you're using, and what is and is not likely to change over Perforce upgrades -- your friends in Perforce Support can help there.
- Consider all users, especially power users. Make it easier for "the masses", without denying control for power users (unless strict control is really necessary).
- Consider making back-doors so that users can access alternate workflows to maintain productivity if some part of the layer breaks when the guy who wrote it is on vacation.
- Recognize the value of investing in a long-term infrastructure team that such systems demand.
- Build and maintain a team large enough that people have time for knowledge transfer in addition to delivering productivity-enhancing features. That reduces the "human SPOF" dependencies in your environment.
Of course, Perforce itself is evolving to make using it easier. For example, the exciting Streams functionality coming in 2011.1 is the ability to simplify workspace creation and management. If the popular mainline model and TOFU scale work for you (and they probably do), then you're telling Perforce it can make certain assumptions about the way you want to work. In exchange, some complexities of the "ultra-flexbile" nature of Perforce fade away.