The Value of Programmer Lore and Standardization

Standardization fosters the growth of programmer lore, and there’s nothing more valuable to your organization.

There’s an unquantifiable benefit that comes to every company that has an IT department: Programmer lore. Programmer lore is what programmers learn (and share) over time as they work with a set of tools. Programmer lore is what you’ve barely started to acquire when you come out of school (unless you’ve been doing a lot of coding outside of class). Programmer lore is invaluable.

At its simplest, programmer lore is “knowing what the error message really means.” Early in your career, when your code or build blew up and someone leaned over your shoulder, looked at your error messages and said, “Oh, yeah. OK. So scroll up, scroll up, scroll up. There it is. You need to <insert solution here>”—that person was demonstrating programmer lore.

Programmer lore is more than just knowledge, though. Lore includes, for example, flexible, conceptual solutions for problems both micro and macro that work with the organization’s programming standards, toolset and platform. Programmer lore is a shared understanding of how to think about a problem in a way that leverages the tools available to the developer.

Lore isn’t having a ninja developer, either. Lore is useful because it’s shared. Lore is a team resource and, while you can buy new team members, you can’t buy team lore.

Leveraging Your Toolset

I am very fond of new technology, but programmer lore is why I tell my clients they should adopt a platform/toolset and stick with it as long as they possibly can. You shouldn’t abandon a toolset/platform until there’s something you really, really want to do that can’t be done with your current toolset/platform. At that point, you should move to the youngest viable toolset/platform and plan (at least initially) to stay on that platform until you die. Maybe longer. Sticking with a platform lets developers grow their store of lore.

Don’t get me wrong, Part I: I have no use for people who say that whatever platform/toolset they’re using is all anyone will ever need. To quote Vince Gill: “They stopped playing Elvis. They’re going to stop playing you.” Your toolset of choice will, eventually, need to be replaced. I started with COBOL running on the VAX/VMS operating system, and I’m currently using Blazor in .NET 5 running in the browser of your choice (and I can find people to tell you that I’m not keeping up). Change happens. Accept it.

Don’t get me wrong, Part II: When you shift platforms, there’s actually a lot of lore that you carry with you: Conceptual tools that work everywhere you write code. In fact, while learning a new toolset does lead to mistakes, it often turns out that the biggest problem in moving to the new platform is carrying too much lore with you: you keep applying inappropriate paradigms to your new environment. Change happens. Change with it.

Building Lore

But, while change happens, nothing is more valuable than a team of developers who know their tools/systems/organization well enough that they know where all the bodies are buried. And that comes from letting developers work with a toolset for as long as you possibly can.

This is, for example, the reason we have tool suites like the Telerik DevCraft bundles: The first tool or control the vendor builds for any platform takes time and costs money. The second costs less because of the lore the vendor’s developers grew while building that first tool. These vendors aren’t stupid: it would be foolish to just build one tool for every platform and never take advantage of what was learned in building the first tool for any platform. They build suites because lore is valuable.

And this is also the argument for keeping your toolkit small. There are two problems with letting the size of your toolbox increase. First, it takes longer and longer for any developer to build up a store of lore on all of the tools. With a large toolkit, developers compensate for that by becoming specialists in particular toolsets instead of the whole toolkit.

Which leads to the second problem: Those specialists have no one to share their accumulated lore with. Instead of lore becoming a shared resource that is built up and drawn on by all team members, lore becomes a private treasure, accumulated and used by a select few (or even just one) team members.

Since people do move on, losing one person from a small group is a bigger cost than losing one member of a large group. This is why agile teams prefer developing overlapping skillsets among members (Dan Radigan has some sage advice on handling specialists).

Programming Standards and Lore

So I’m suspicious of the “this is the best tool for this problem” argument and assembling “best of breed” solutions. I’m a big fan of software standardization so that the team can build lore (until, of course, it’s time to go to the next platform). Besides, if your platform only offers one solution for a problem and it’s not available in your toolkit, it’s a flag that it’s time to leave that platform.

And lore cuts both ways between vendors and developers. I’ve never seen a study on the topic, but if you have a developer that bought the Telerik Grid in the past and now needs more tools … I bet that developer begins by looking at other Telerik packages. I don’t think those developers are being foolish or lazy in, effectively, implementing component standardization—they’re recognizing the value of lore. Once you know how a vendor’s tool works, you’ve got insight into how all of that vendor’s tools work.

To put it another way: If I’m your boss and you want to convince me that, for this project, you need to use a new Grid from a new vendor, you’re going to have an uphill battle convincing me. You’d have far more luck arguing that our current tool vendor isn’t meeting our needs (as demonstrated by the need for this new Grid) and that we need to adopt a new toolset.

Similarly, I guess, there are benefits in getting different solutions from the same vendor (a UI package and a source control system, for example) because those solutions somehow “work together.” That’s not a compelling argument for me (though I’m glad to reap those benefits when they exist). I’m a developer: I can make anything work with anything else (eventually). On the other hand, if the two solutions let the team leverage knowledge gained in one solution when using the other … well, then I’m interested. That’s programmer lore and it’s worth a lot to me.

Supporting Standardization

Of course, tool vendors are keenly interested in supporting standardization (they call their products suites because they want you to buy in bundles). That's good for developers because well-designed suites help build programmer lore. Web developers who adopt DevCraft, for example, get a suite of both Telerik .NET and Kendo UI JavaScript tools that not only share a family resemblance but allow shops to standardize both within teams and across the enterprise (DevCraft includes UI components, reporting solutions, document processing libraries, and automated testing/mocking tools). The Progress Telerik team continues to add to this toolset so that even new tools let you leverage your existing lore.

Editor’s note: Learn more about DevCraft’s free 30-day trial, or dive in now:

Try Telerik DevCraft