Strumenta 
Why this interview?
Peter Strong is a software engineer, architect, and he spent most of his career in the telecoms space, with companies like Nortel Networks, Ericsson, Arista Networks, and in a lot of smaller companies, startups in the communication space, like Meriton Networks, BelAir Networks, Lumina Networks. We talk with him about his project Dark Matter focusing on the problem that he was trying to solve when he created Dark Matter.
So, the basic idea is having a Java-based framework where you could describe schema of all of the data that you wanted to manage, and then to be able to easily translate that into an interface through which you could manage it.
So the basic concepts have gone from strictly modeling data more towards being able to define concepts associated with anything. So as time went on, moving into different domains, what I found was that the same problems occur again and again. You come across a particular domain, you see people struggling to represent the concepts in that domain, and so the basic concepts behind Dark Matter, like defining attributes, types, classes, and then generating code from it, or even just representing configuration data associated with different domains, it occurred again and again.
So basically, from the Dark Matter site, we can provide a link later, you can download this starter project. And the idea here is that we have no real code associated with your DSL at the starting point, just a framework. So from here, you will do basically a bootstrap of the project, and it’s simply asking you for a package associated with this. So if we do something like, we have example, and that example DSL, xDSL. And then it will ask you for, basically, a file extension or an abbreviation of your DSL. So in this case, we’ll do xDSL. And it will generate a variety of things.
So basic concepts, and this is the thing. It comes from an object oriented perspective. It’s based on Java.
Federico Tomassetti:
Hello, Peter. Thank you for joining us today.
Peter Strong:
Federico. Likewise. Good to see you.
Federico Tomassetti:
Good, good. I really appreciate the possibility to interview you. We have a lot of questions that I want to ask you, so I will start right away. And the first thing that I will like to ask is to tell us a bit about yourself.
Peter Strong:
Right. Well, I’m a software engineer, architect, and I spent most of my career in the telecoms space, with companies like Nortel Networks, Ericsson, Arista Networks, and in a lot of smaller companies, startups in the communication space, like Meriton Networks, BelAir Networks, Lumina Networks. So I come from a networking background, and for me, a lot of the aspects there have to do with the configuration data associated with networks and understanding it, and thus the reason I started this project.
Federico Tomassetti:
Good, good, good, and indeed we will talk about this project, Dark Matter, today. And well, I would like to start a discussion about Dark Matter, focusing on the problem that you were trying to solve when you created Dark Matter.
Peter Strong:
Right, right. So within the networking space, of course, like I said, it’s very data-intensive. And so one of the first things was trying to come up with a relatively straightforward way to represent the concepts of configuration data associated with networks, but also then to allow it to be managed through a web-based interface. And when this started back in 2010, the choice then was to use Google Web Toolkit.
Peter Strong:
So, the basic idea is having a Java-based framework where you could describe schema of all of the data that you wanted to manage, and then to be able to easily translate that into an interface through which you could manage it.
Federico Tomassetti:
Okay. And in this case, the intended users of your system would be a network engineer, right?
Peter Strong:
Yes. In that case it would be users who were configuring their network data, and being able to basically understand how all that data fitted together. So things like relationships between objects and things was very, very important, and Dark Matter made that a very clear process.
Federico Tomassetti:
Good, good. And okay, you say the project was started over 10 years ago using a technology that at the time was very interesting. Today is less common. So can you tell us a bit about the portability of this solution, and how the technological stack evolved over time?
Peter Strong:
Right. So the basic concepts have gone from strictly modeling data more towards being able to define concepts associated with anything. So as time went on, moving into different domains, what I found was that the same problems occur again and again. You come across a particular domain, you see people struggling to represent the concepts in that domain, and so the basic concepts behind Dark Matter, like defining attributes, types, classes, and then generating code from it, or even just representing configuration data associated with different domains, it occurred again and again.
Peter Strong:
So as time went on, I basically began to build pieces that were more along the lines of a domain-specific language, to represent things, and provide behavior associated with those concepts.
Federico Tomassetti:
Good, good. So I imagine that given you have created essentially a DSL, you were able to capture what was relevant to you initially. So a network configuration where you instruct from the technologies that we’re using for the optimum implementation. In your case, for code generation. So make this logic survive all these technological transitions, right?
Peter Strong:
Right. So that is one of the benefits of having a base model for whatever it is that you’re doing. Now, still, most of my work has been in Java, but I’ve also used these mechanisms to generate Python, to generate Golang, to generate other forms of schema that are required. And in some cases, I guess, augmenting existing DSLs in a way that adds more descriptive aspects to them.
Peter Strong:
One area where I’ve done that was with Google Protocol Buffers. So we were using Google Protocol Buffers to transmit the status information, performance data, and things like this, from devices. And Google Protocol Buffers is an incredible compact form of sending data of one place to another, also makes it so that if there are changes in the data from one version to another, it seamlessly handles those things. Fantastic mechanism.
Peter Strong:
What was missing was a way to be able to document that data, which was very important for the end users of it. So in that particular case, I simply modeled the Google Protocol Buffer concepts in Dark Matter, but then allowed the engineers on the device to extend it, with definitions like succinct descriptions of what each of the fields meant, the units involved, and so forth, and then use that to generate the Google Protocol Buffer stack but also generate FrameMaker documentation.
Peter Strong:
Once again, that’s an older form of things, but the documentation guys love this because there was a single source of truth for what the data was. You were able to have the Google Protocol Buffer specification for the device and for the clients of that data, but then also get the documentation from it, which was being built as part of the build process. So, it basically helped everyone communicate and get useful information to make using the data easier.
Federico Tomassetti:
Yeah. I imagine that the documentation for this kind of system is very important, because probably they’re going to last for a while.
Peter Strong:
Well, it lasts for a while but then it also changes on a fairly frequent basis. So having that as a clear mechanism to say, you know, we’ve added new fields in here, or more importantly, perhaps, we’ve changed the meaning of something, and it’s immediately reflected in the documentation, and in the API that’s been generated from this code. So yeah, documenting things, very, very important.
Federico Tomassetti:
Good, good. So we talked a little bit about the advantages, we gave an idea to our listeners of the main goals of the project. Maybe this is the right time to show a little bit how it looks like.
Peter Strong:
Sure. I can just give you a short demo of basically a starter project. So let me just see here. Share screen. And now, I’m not sure if this will… Shift. Okay. Okay. So can you-
Federico Tomassetti:
Yes, I can see it. I can see Eclipse.
Peter Strong:
Okay. So basically, from the Dark Matter site, we can provide a link later, you can download this starter project. And the idea here is that we have no real code associated with your DSL at the starting point, just a framework. So from here, you will do basically a bootstrap of the project, and it’s simply asking you for a package associated with this. So if we do something like, we have example, and that example DSL, xDSL. And then it will ask you for, basically, a file extension or an abbreviation of your DSL. So in this case, we’ll do xDSL. And it will generate a variety of things.
Peter Strong:
So now, if we refresh our project, we’ll get some interesting pieces out of it. So from this it creates a file structure that provides you with what I would call the meta-schema of your DSL. So I’ve broken it out here. All of this can go into a single file, but I tend to break it out into various pieces.
Federico Tomassetti:
Sure.
Peter Strong:
So basic concepts, and this is the thing. It comes from an object oriented perspective. It’s based on Java. So you will see things like class definitions. These wind up being turned into actual Java classes of different types, for instance, abstract classes, structural classes. And in this particular case, I’ve just had it generate a couple of basic concepts to show you the idea here. So you have your class definition, and then you have references to must-have, or mandatory attributes. So in this case it is a named concept, and it has a variety of other attributes that it may have.
Peter Strong:
Your attributes are defined, likewise, as attribute definitions, with names. So something that looks a little bit like Google Protocol Buffers, although this was invented prior to that time, is unique identifiers for each of these things. This allowed for very succinct, compact transmission on the wire for Google Protocol… Or, not for Google Protocol Buffers, but for Google Web Toolkit.
Peter Strong:
So the idea was, you weren’t constantly transmitting strings all over the place, you wound up with this. Now, at some point we may talk about the future of things. I may wind up changing this so that you don’t have to provide this. But at the moment, it is the way that everything is represented within the framework. So you have to provide a unique identifier within a given module for each of your different pieces.
Peter Strong:
So you have your classes, you have your attributes. You can also define types, so things like your enum definitions, you can have. And then, there’s something else which basically allows you to define complex types with required parts and optional parts, and come up with basically very succinct microgrammars for particular attributes. So in this case, you have a reference to a Concept B, some strange things to say why you’re doing this, this is to provide, say, an alternate name for something.
Peter Strong:
And then, so you can specify it in a single line without very much syntactic cruft, as I would say, so that you can simply say, an example of this attribute would be… And I’ll show you the instances of these objects. William prefers this, Bill… And then you can put in an optional note or something else like this. But from this, you can build up fairly complex structures that are very easy to write into a file.
Peter Strong:
Those are the basic pieces. From that, like I said, it generates a series of code that you can then extend with your own behavior. For instance, for each of the concepts there there’s a separate file that’s generated, and you can go ahead and extend this with behavior. Anyway, there’s a lot of different aspects associated with that that we won’t have time to cover, at least here.
Peter Strong:
But then, the actual example of the data associated with this DSL, it would be you have a module. Basically, the whole thing is set up in terms of being able to specify modular chunks of specification. Modules allow you to include other modules. And then within this, you always start the type of object that it is that you’re defining. If it’s a named object, you have its name, and then the attribute values associated with that.
Peter Strong:
So, in this particular case, we have the alternate specification and this is an example of how you actually specify this in the grammar. The nice thing about all of this is that you don’t have to do anything special in terms of parsing or figuring this out. This is all built into the framework, so you can get started very, very quickly, and then if you actually run, in this case, the test associated with this, it will parse this file.
Peter Strong:
And in this case all it’s doing is it’s finding all of the Concept As and printing them in this format, which is simply called Object Instance Format. And then, it’s also showing you the same thing dumped in JSON format, which obviously very familiar to everybody, but it’s the way that the object instance format works is that it has a lot less in terms of quotes, and colons, and braces, and so forth. So it’s cleaner for a lot of users to be able to specify. But if you want the data in JSON you can have it in JSON as well.
Peter Strong:
So from there, you can also just do… One of the other things that I always find starting a project myself, is that it takes time to figure out how to build the project and deliver it. And with this starter project, all of that stuff is taken care of for you. So you can do a Maven build, it will go ahead and create what’s called a shaded JAR, which basically has the entire set of code built into it. It’s self-contained. Now, what I’m not sure is if I switch windows, can you still see my screen?
Federico Tomassetti:
I still see Eclipse.
Peter Strong:
Okay. Right. Anyway. Suffice to say, you can set up an alias that points to that shaded JAR, basically Java minus JAR and your shaded JAR, and then it will start this base application that you have now built, and you can start going from there. So you don’t need to try to figure out, well, how do I actually deliver this to somebody? It’s done for you.
Federico Tomassetti:
I can see you have put a lot of effort on engineering this, and make it really usable for your colleagues.
Peter Strong:
Right. It’s one of those things that’s always a pain. You can see a very simple example of something, but when you actually go to deliver it to somebody, that can be a bit of a challenge. So I’m trying to make it as straightforward as possible.
Federico Tomassetti:
So if I understand correctly, using Dark Matter, someone can define some data structures, but also a lot of constraints for this data structure, and then someone else can actually define the data that respected that structure, right?
Peter Strong:
Correct. Yes. Now, for instance, I was going to show you, because I’m not as… New share, let me just see here. Yes. So let me just try this. Ah. Okay. So for instance, this is in another project called Polymer, that was built on top of an open source project called Plastic, that came out of OpenDaylight, which is an open source project for an SDN controller.
Peter Strong:
So in that particular case, there were a lot of very powerful concepts for doing model to model mapping and so forth. So just to show you, it isn’t just very simple things that you can do with this in terms of an attribute and a value. For instance, here, there was a concept of having reusable patterns, which is a fairly common thing when you are doing work with data models, and being able to translate or recognize particular things.
Peter Strong:
So in this particular case, the idea was that you could define a pattern that you could then refer to in another location. Often, you find in different grammars that because they’re hierarchic, often things are defined in JSON or in XML. They’re hierarchic. And so if there’s a piece of information in there that you want to use over and over again, there’s often not an easy way to do it. With the Dark Matter setup, you can actually have it so that you refer to this as a first class thing, and then in another piece of the grammar, you can simply say, “I’m going to make a reference to a Plastic pattern.”
Peter Strong:
And the pattern is defined in this case in JAVA regular expression format. It allows you to specify groupings so that you can easily reach into the pattern and pull parts out of it. Once again, this is something that you can refer to in another aspect of the grammar to say, “Match this pattern and pull out Part One, and then insert it in some other structure or something else like that.” And it also has the concept of defining a test for this, so that you could easily say, “I want to use the Flash separator pattern,” so this is a reference attribute to this pattern, and give it some input, and say, “I expect that Part One’s going to be one, two, and Part Two is going to be three, four.”
Peter Strong:
And this way you can actually set up automated testing of your patterns that you’ve defined, to make sure that you don’t break them. Somebody might come in and make a change to this, but then you can run an automated test and go, “Nope. Somebody has broken this. Everybody expects this to behave in this way, and it doesn’t.”
Peter Strong:
So just in terms of expressibility of things like patterns, things like embedding JSON within the actual Dark Matter grammar as well, you can drop in JSON, you can drop in JavaScript, you can drop in Python. The way that the attributes are defined is pretty powerful in terms of defining the type. So it allows you to combine many different things within the structure.
Federico Tomassetti:
Okay. Well, I understand the embedding JSON. I’m not sure what the embedding JavaScript or Python are useful for.
Peter Strong:
Right. Well, in the particular case of JavaScript, I was working on, basically, an extract, transform, load pipeline, and we were doing model-to-model translation of things. And it turned out that DSLs are very powerful, but sometimes it comes down to, if you want to cover everything in the world, it becomes unwieldy, and it’s just too much. So you fall back to a programming language. And in this particular case it turned out that the network engineers, who were doing the model-to-model translations, were familiar with JavaScript. So basically I made it so that you could create, for instance, small, reusable functions, where you wanted to alter an attribute that was going from one model into another, but you could define it in JavaScript and execute it, because Java actually has the Nashorn implementation of the JavaScript engine in it.
Peter Strong:
It was very trivial to say, “I can define a JavaScript function,” which takes an input and gives you an output, and build it right into the language so that you could use it to define basically a function-oriented programming to simply say, “Here’s a reusable function that I can use to manipulate this,” and then the various network engineers could build a little library of these things and express what they need them to do. So, just another possibility. Once again, depends on the domain, and what your users want.
Federico Tomassetti:
So if I understand correctly, with your language, you have the possibility of representing directly a lot of data processing features that you may want, like recognizing patterns, but you also have the possibility, basically, of scripting, by using JavaScript or Python, so that you can cover those corner cases, and this is useful because if you didn’t do that, the alternative would be evolving the DSL to be as powerful as a general-purpose language but at that point you lose all the advantages of having the DSL?
Peter Strong:
Yes. So one of the other things is, I guess, a combination of things across domains. One of the other projects that I’ve worked on more recently had to do with managing instances of AWS, compute instances, so basically setting up virtual machines and things like that. And that got to be somewhat challenging because sometimes you would have to do basic bash scripting, for instance, to configure various things. And then in other cases you also had to use things like Ansible, an existing very powerful mechanism for doing configuration.
Peter Strong:
I was able to combine those different things to say I can define the instance of a virtual machine that I want, and then have various, what I would call initializers. And the initializers were an abstract concept, but you could then embed bash scripts within one type of initializer, Ansible scripts within another type of initializer, and use them interchangeably so that you were able to combine concepts across domains to achieve a particular result, which was basically configuring these virtual machines for use. So it helps, definitely.
Federico Tomassetti:
Wicked. So we have seen that Dark Matter is very flexible and so can be applied to many different domains, but I think there was one particular project that we discussed, initially by email, and was one project where your view is Dark Matter, and maybe we could talk a little bit about that project, if that works for you?
Peter Strong:
Sure. I’ll just… I guess I can stop sharing here, now, perhaps.
Federico Tomassetti:
Ah, yeah.
Peter Strong:
We can come back to sharing if required. Yeah. Okay. So, which particular piece were we referring to?
Federico Tomassetti:
I think it was a project about writing an NMS project using Dark Matter that previously was written in Clojure.
Peter Strong:
Oh, right. So this is basically what I would call a life cycle service orchestration product that required information from a disparate set of network devices. So we’re talking about integrating data from Cisco, Juniper, Huawei, many different network management devices. But to pull them together and represent them in such a way that the users could visualize the entire network from end to end.
Peter Strong:
So the challenge there was primarily that you had network engineers who understood, for instance, the command line syntax of a show run config on all these different types of devices, but they’re all subtly different. And the process for doing this in terms of integrating the data was originally that the network engineers would go through a particular data dump, try to understand it, and then write up stories that would then be passed on to the development team to say, “Okay, for this type of device I want you to extract this data.”
Peter Strong:
So it was a very labor-intensive process, as it were. So when I came to this and looked at it, the first thing was, how do I understand what the data is coming from these devices? So I created, basically, a configurable parser for this form of data. So command line syntax is very, very common in network devices, but they’re all subtly different. So the first thing that I gave the network engineers was a mechanism to say, “You can run this parser over the data and get a summary of the structure of the information.”
Peter Strong:
So how they configured it was defined in Dark Matter. So it was simply a concept of a indent-delimited parser for this data. From this, they got a data catalog which showed them the entire structure. So that was immediately useful because it allowed them to communicate to the development team exactly what data it was, and give examples of what it was. So we got that far-
Federico Tomassetti:
Yeah, if I can interrupt you, I imagine that in this situation it’s very important to be precise, and I think that what I can imagine happening is that when network engineers could only describe in words the format of the data, they inevitably miss some details. So they didn’t have a way to, let’s say, find that the bug is in the description.
Peter Strong:
Absolutely. And the thing was, is that each of these different forms of command line syntax can have different forms, with basically optional pieces in them, mandatory pieces. But the optional pieces would often change, and so it was important to recognize the keywords that were used to indicate pieces of optional data.
Peter Strong:
And of course, these dumps from particular devices, tens of thousands, or hundreds of thousands of lines long. So the network engineers, they tried to cover the use cases that they were thinking of, but often they wouldn’t catch everything simply because there was so much of it. So cataloging the data and giving a very clear indication of all forms of the data was a real bonus, because they would go, “Oh, I didn’t realize that you could also have this form of the data, or that form of the data. Okay, so I need to put that in my story as well.”
Peter Strong:
So it helped with the communication, just to start with. But then, it came down to, well, what’s the model into which we wish to turn this data? What do we want to turn it into? So I worked very closely with the CTO, director of standards and the director of solutions architecture in this case, and together we came up with an abstract model of what networks look like, in terms of their different layers, the dependencies between the layers, and that was actually put together into a patent for the company.
Peter Strong:
So that was the other aspect, and likewise, that was modeled in Dark Matter. Now, it comes down to we have what’s on the device, what’s the abstract model that we want to work into, so the network engineers were trained on what that model was, and then was, now, how do I go from one to the other? And that was where having the DSL that allowed them to do the model-to-model translation came into play, and coming back to, now we need reusable functions, because a certain form, say, of an IP address, or a site name, or something else like that, had to be normalized or whatever.
Peter Strong:
So now it came down to, we could extract the data, provide a catalog for it, we have a model to which we wish to translate it, and now to join the things together, to connect the dots, we come up with a DSL that lets them express how to pull the data out and turn it into the abstract model.
Peter Strong:
So now we go from, we have to write everything up in a very long, tedious error-prone format, into here’s a clear definition of what we need to be able to do. We can run it basically to process a particular configuration file from a device. They can easily look at the output in the object instance format. It’s cleaner to look at than JSON. JSON is, once again, very, very useful, much better, for instance, than XML, but XML has its purposes as well. But it’s a very clean format. They can look at it. They can eyeball it very quickly and go, “Okay, now I’m going to turn this into another format,” which wound up in a graph database. And that was based on the schema designed for this abstract model of what the network looked like.
Peter Strong:
So it significantly shrunk the delivery timeframes from, here’s a new device that needs to be integrated into the overall view of the network, to now we actually have the data for it extracted, and represented in a model, and available for use by the product.
Federico Tomassetti:
Okay. So if I understand correctly, before using Dark Matter, basically the network engineers had to look at logs, understand the format, describe it, give it to developers, the developers were trying to implement it. Eventually they will recognize corner cases for which there was not a description, or maybe the description wasn’t absolutely precise, maybe some details were overlooked so they had to go back with the network.
Peter Strong:
Yes. Right. And so the iteration time in there was quite long. So any situation where you can increase the level of communication and clarity and reduce the iteration time for whatever it is you’re doing, I think that’s one of the benefits of a DSL. Now, that being said, it does take more study, upfront knowledge of the domain, in order to create the DSL. So this is one of the things that sometimes people will look at, “Well, why is it taking this long?”
Peter Strong:
Well, there’s what I would call a potential hump that you have to overcome. It’s the learning of the domain that takes the time. But then, once you’ve learned it and you’ve communicated the way of how to express it to your end user, then you see the benefits of it, and I think in any organization, overcoming that initial resistance… It took you six months to create this thing, but that’s a very long time. But if you then compare that to the effort involved and the time involved and the errors that you eliminate from whatever process it is, I think there are tremendous benefits there. But it’s always, I find, an education process in terms of the benefit that you get out of some forms of DSL versus continuing to do it the way you’ve always done it.
Federico Tomassetti:
I think it would be interesting to discuss more about the resistance that the different authors may have, because I can imagine that the domain experts, in this case the network engineers, could resist, for example. They could say, “I don’t want to become a developer, so I will just give you the document, please figure it out.” Or maybe the developers could resist, say, “Okay, it’s our job to write the system, why these engineers are trying to do that?” Or maybe the organization could resist because they could think, “I don’t want to make the investment in creating the DSL because I don’t know how soon I will recover my investment.” So these are ideas that comes to mind. I don’t know if any of these happen, and I would be interested to hear what really happened.
Peter Strong:
Yeah. Strangely enough, from the user perspective, I find less resistance, because if you successfully… You sit down with them, they’re your customer, you sit down with them, you understand their pain points and what causes them grief, and what causes them to be frustrated with how long it’s taking to do something. If you deliver something that actually solves those things, or lessens those problems, I think they’re quite receptive.
Peter Strong:
Now, strangely enough, you tend to get more resistance, I’ve found, say, from development communities and from management along the lines of what you were talking about. There seems to be… In some cases it’s simply momentum, as in, an object at rest has to stay at rest. “This is the way that we’ve done it. We’re familiar with these mechanisms. This is new and we don’t want the change.”
Peter Strong:
Then, it could also move into, “This is new, and it actually eliminates part of the work that we need to do.” And again, this depends on organization. Sometimes cultural background. I’ve run into that as well, where the amount of work that people do, if you try to reduce it, they resist that, because they think eventually they’re going to be out of a job. But in actual fact, what you’re doing is you’re making them more productive so that in the end the company is more productive. They’re getting more value from the people that they have on staff, and that’s a good thing, because now the company is just spending less time doing one thing over and over again. They’re actually increasing their revenue, as it were, because now they can take on more work, get in more customers, end customers, and go that way.
Peter Strong:
So, there are so many different social landscapes into which you have to sell these ideas. But I think in the end, when it comes down to the organizational resistance, it has to come down to, yes, there’s an upfront learning cost here, but once you have actually overcome that, you are going to be able to do more work, get more things done for your end customers, and therefore you’re going to be more profitable if you take this kind of approach.
Peter Strong:
But it can be a tough sell, to come into a new domain, understand it well enough to give a very good proof of concept. It can sometimes be a challenge. But I guess the one thing that is good there is that so many domains exhibit the same kinds of patterns in terms of what they’re attempting to do. Once you’ve got enough of these things under your belt, you begin to be able to take advantage of those patterns, and go, “Okay, I’ve worked on a project like this previously, I can dust off a piece that I already have, drop it in, and get moving much more quickly.”
Peter Strong:
But for anything, there’s always that learning curve, and explaining the benefits to the developers involved, to the organizations involved. Sometimes you’re successful, other times you’re not.
Federico Tomassetti:
I think this is why these kind of discussions are very important for the community, to show examples of where this work and what kind of benefits it brings, and also discuss the fact that yes, resistance is normal. We experience it. There are reason for it, but in the end, if organization are willing to work on that resistance, there is the possibility to improvement. I would like to talk exactly about the advantages that you think this solution has brought in practice, compared to the previous system.
Peter Strong:
Right. In this particular case, it was really the network engineers, or actually, it was more of a pre-sales engineer that I helped in this case. The particular company that we were doing this work for was a new potential customer, and they needed to see results in a relatively short period of time. And this person had basically come into the company, really only maybe a month or so prior to my having put this entire mechanism in place.
Peter Strong:
And he was able to, within a month of coming in, he was able to integrate new devices that this customer had been dealing with, that we hadn’t even seen before. So the existing network engineers hadn’t been dealing with this device before, had no experience with it, but this gentleman came in, I showed him the basic concepts, he grasped them very, very quickly, and was able to do the integration and do a proof of concept for the end customer within a very short period of time. And in the end, we wound up securing that customer, and it was a big win for the company.
Peter Strong:
So it was basically, to be able to bring somebody in, and within a month make it so that what had maybe in the past taken six months for an experienced network engineer to accomplish, going through the previous development approach was pretty satisfying, I guess I’ll put it that way.
Federico Tomassetti:
We can say that speeding up development by six times is quite an interesting achievement, probably. Many companies are interested in that kind of improvement.
Peter Strong:
Indeed. Well, I would hope so, because in the end, it means you’re bringing in more revenue because you’re able to do more work with the same amount of people. Some people will look at it you can do the same amount of work with fewer people, but I don’t think generally companies will do things that way. They have employees who’ve been working with them for a long time. They understand the landscape of what it is the company is trying to do, and I don’t think many companies will actually look at it as an opportunity to get rid of people. I think they will more look at it as, “We have this backlog of potential customers that we haven’t been able to deal with. Now we can actually start dealing with them and expanding the amount of work that we can do.”
Peter Strong:
So anywhere where you can reduce the amount of development effort to satisfy an end customer I think you’ve got a tremendous business advantage there, and it’s just once again, you do have that potential hump you have to overcome. You have to understand the domain well enough to do something that’s useful enough to get that reduction in the iteration time, to perform whatever task it is that you’re doing.
Federico Tomassetti:
Yeah. And I also think that from the point of view of the domain expert, in this case the network engineer, it must be very satisfying to be able to achieve more in the same time. In a way, you compress the boring, mechanical part, but your actual contributions stay the same, you’re just able to produce it as a much smaller time.
Peter Strong:
Yeah. Absolutely. And I think they found that… I actually had some comments or recommendations on my LinkedIn from the point of view of the people who were my internal customers, who were just so happy that they were able to do this. Because it’s tedious and time-consuming, especially within these complex of networks, to go through all of this data. So anything that lets them understand and grasp the data more quickly, and then actually see the results of their effort for their end users, I think is very satisfying to them, and very energizing for them. Because it was like, “I don’t have to do all of this work up front and then wait several weeks for some result to come out.”
Peter Strong:
And then that brings to mind another thing which is context switching. The more time you leave between various parts of whatever it is you’re doing, you lose your context, and then two weeks later, somebody comes and says, “Hey, I’ve got that data. It’s been extracted into the database. Can you check it?” And you go, “Well, now I’ve forgotten what that is, and now I have to go back.”
Peter Strong:
And so context switching is a cost as well, and I think that’s one of the things… I don’t know if I’ve ever really put it that way, but I find myself, if I’m working on a project, if I can work that project through to completion without then being interrupted by many other pieces, I tend to be more productive. And I think that that’s what they found, was that they had the context, they understood the customer problems they were trying to solve, and the data associated with this, and that they were able to go from, “Here’s the data,” to, “Here’s how we actually want to present it to the users so that we can see how their network is connected, and do it in a week as opposed to several months.” I think, “That’s great, now we’ve done that, and now I can move onto the next customer and solve their problems.” So yeah, context switching, the more of it that you can reduce I think the better off you are.
Federico Tomassetti:
Okay. We are running out of time in a few minutes, so I want to be sure we cover a few more points. One thing that… Well, I think that you occurred many times in discussion about domain-specific languages and model-driven development in general is that they seems to be used mostly in Europe and less in North America. I think you’re based in North America, right?
Peter Strong:
Yes.
Federico Tomassetti:
So can you comment on this?
Peter Strong:
Yeah. It’s more of a feeling. I can’t point to substantive data on this, but I tend to find that most of the blogs that I read, and people that I follow, tend to be more based in Europe than in North America. And the only really big code generation conference I’ve ever been to was actually in England, the code generation conferences that were there. I was only lucky enough to go to one of them.
Peter Strong:
And it was one of the most, I guess, professionally satisfying conferences I’ve ever been to. Simply to be surrounded by people who, I think, think the same way in terms of what the benefits of domain-specific languages, model-driven engineering, code generation, and these kinds of things, are. And once again, I’m thinking back, this was quite a while ago now, but I would say basically all of the people that I’ve met there were from Europe. And it’s quite puzzling. I don’t know if it’s a cultural thing, if the background of people in Europe tends to be more formal from the point of view of software development, not so much the move fast and break things which tends to be maybe more of a Western… Well, when I use it in that term, Europe would be involved in Western civilization, but I’ll say North American view of things.
Peter Strong:
I’m really not sure what the difference is, but it just seems to be that way. And I’ve worked with people in different organizations in large telecom companies, for instance with Ericsson, and even within Ericsson I found that there was a core set of people in Stockholm who were very aligned to model-driven engineering and code generation and things like that. Whereas, the local office was not nearly as aware of these kinds of things. And I’m not sure. It’s an oddity. But it’s good. I appreciate the fact that there is a community there, and you are part of that community, and educating people on these things and helping us with different approaches to this. And yeah, I appreciate that you are all there.
Federico Tomassetti:
Yeah. Unfortunately, I never attended a code generation conference, but I heard many people talk about, so I wasn’t that lucky. But it’s true that if you’re based in Europe, maybe it’s easier to get in contact with some of the people working the area. For example, in my case, during my PhD I was able to spend six months in Germany, working with Markus Völter and his team that had a lot to learn about this work.
Peter Strong:
Yeah. Indeed. I mean, yeah, geographically traveling within especially the mainland of Europe and everything else is considerably easier than in North America where things are fairly distributed in terms of distances, cost of getting to different places, and things like that. And being in Canada, at least staying in Canada, it’s even worse, because we’re much more sparsely populated. And things like rail travel and whatnot, it takes a long time to get to different places. So you’re pretty much, you have to go with air travel, and yeah, it’s definitely much more expensive to get around. So yeah, definitely could be.
Federico Tomassetti:
Good, good. And I think that before we close, one thing that we need to discuss is the future of Dark Matter. So if you can tell us what you’re planning for the project?
Peter Strong:
Well, I think in some regards this opportunity that you’ve given me has really wanted me to do a lot more in terms of proselytizing, presenting this, and educating about the benefits of this. So I may wind up taking it in the direction of calling it something like Dark Meta, because most of the information… There’s not really Dark Matter data so much as it’s the meta information around different domains, and being able to express it, being able to combine them, and this kind of thing.
Peter Strong:
I’ve been using this in basically every company that I’ve been in for the past decade, but I haven’t really had the time to put into educating people about it, documenting all of the things that are there, putting together a weekly or a monthly blog about how to approach different things. So I think this is good impetus to start looking at that, and investing a bit more in making it available to more people.
Federico Tomassetti:
Good, good. And is there a website where people can find out about Dark Matter, or a link we can share?
Peter Strong:
Yes. I can provide you with those links. It’s available on GitHub. The DM Start Project, which I think right now is going to be the best place to go. It’s quite small at the moment, but I will basically extend the documentation there to go through some of the things that I showed you there today, just in terms of here are the basics of how you get started, and then the idea would be, I can expand on that to say, “Okay, here are some examples of more real-world things, instead of just a Concept A and a Concept B. Let’s actually walk through creating something from scratch that is real.” So I’ll provide you with the GitHub link.
Federico Tomassetti:
Good. We will add the link there
Peter Strong:
… and we can go from there. Okay.
Federico Tomassetti:
Okay, my final question is this, is there anything you would like to add and I forgot to ask you?
Peter Strong:
Good question. I think we’ve covered most of the things that we had initially talked about. Once again, I would definitely like to express gratitude from the point of view of the work that you have been doing. I came across you because I was doing some work with ANTLR, with which I have never really had much experience. I came across your site, I got a lot of very useful background information that basically allowed me to move forwards with the work that I was doing, and just your commitment to educating people in this area and all the rest of it, once again, I’m very much indebted to you, and keep up the good work. I think there’s a lot of benefit of this for a lot of people. They just need to know about it.
Federico Tomassetti:
Thank you. Thank you a lot for your kind words, and thank you for taking the time for sharing your work, and yeah, it was great. And thank you very much.
Peter Strong:
Thank you, Federico.
Federico Tomassetti:
Okay, bye.
Peter Strong:
Take care.
Link:
